Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
Graham, No I am not using any PythonImport directive neither on the prod server, nor on the test server. On the test server, the only mod_python related directive is : LoadModule python_module modules/mod_python.so I'll try you suggestion about adding some logging messages in mod_python.c. By the way, I just remember that I had one problem to build mod_python on Tru64 with the native compiler (not tried with gcc) because of definition conflict for macro _XOPEN_SOURCES defined by Phyton pyconfig.h. The problem is that mod_python includes types.h without this macro defined to the value used by Python and before including pyconfig.h (Python.h). My hack was pretty dirty : undefine this macro in pyconfig.h to build mod_python successfully. But may be it is responsible for this side effect (unfortunatly this seems the only one...). I'll try to find the time to check this in the coming days... Michel --On samedi 10 décembre 2005 15:00 +1100 Graham Dumpleton [EMAIL PROTECTED] wrote: Just to make sure, are you using PythonImport directive at all? Want to eliminate this as these get run regardless of whether a request against a mod_python handler is received. If the code associated with PythonImport took some time to run, that might be a contributor. Anyway, not sure what else to suggest. I would probably start adding extra logging calls in the mod_python.c file of mod_python so that one could see when the Apache child process init function for mod_python is entered and exited for each process ID. That way could see if that is returning quickly or taking some time. Graham On 10/12/2005, at 10:38 AM, Michel Jouvin wrote: I am still fighting with my mod_python problem on Tru64. I have been able to set up a test configuration with just standard Apache modules and mod_python loaded (no php, no dav, no subversion...) and without any url activating a mod_python handler. The problem remains the same. Just after starting Apache, with no request received by this server, I 'kill -KILL' httpd slave and this leads to the restart of other children that don't succeed to initialize properly. Apache restarts as many children as it can before giving up when it reaches MaxClients. Any idea on how to troubleshoot this and get any useful information to debug this problem ? Thanks in advance. Michel --On jeudi 24 novembre 2005 23:43 +0100 Michel Jouvin [EMAIL PROTECTED] wrote: Jim, I am not totally surprised... I am afraid this is a platform specific issue as we are running mod_python on Tru64. Something like a 64 bits issue. Does it sound a reasonnable possibility ? How to progress in troubleshooting ? Michel --On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher [EMAIL PROTECTED] wrote: Michel, I can't reproduce the problem on debian i386. I put together a script that continually greps a apache child pid and kills it. After killing 200 processes there is no change in the total number of apache processes, and nothing in the apache log other an entry for each process killed: [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died, restarting ... Regards, Jim Michel Jouvin wrote: I don't know If really need to write a script, this is so simple. asa/root % ps -e -opid,ppid,cmd | grep http 15601381048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start 15601631560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start 10863961086105 grep http From this output, you see that 1560163 is the child. Kill it with : kill -KILL 1560163 If you enter again 'ps -e|grep http', you'll see (I am seeing...) the number of httpd processes increasing until the max number (determined by MaxClient and ThreadPerChild). When this max number is reached you get the error message in main Apache error log. Michel --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher [EMAIL PROTECTED] wrote: Michel Jouvin wrote: Graham, I played a little bit with worker MPM parameters. In particular I tested your suggestion to increase to 2 StartServers. This has no effect on the problem. I also tried to raise MaxSpareThread to MaxClient and suppressed child recycling (MaxRequestPerChild=0) to suppress restart of child as it seems to trig the problem with mod_pyton. No effect. I also checked the load during all these tests. Almost no request. So the heavy load syndroma you described doesn't seem to apply in this case. Again, one month ago I tested during 2 or 3 days an Apache configuration with mod_python loaded and without any url to trig its usages. And the problem was already the same. So it seems this is not related to mod_python usage (it happens even if you didn't execute any Python code) but rather to mod_python interaction with other Apache components. Michel Michel, I'm not able to reproduce the behaviour on debian stable (i386) with apache 2.0.54, but I'm not sure if I'm testing this correctly. Could you create a test script (bash or python) that will produce
[jira] Resolved: (MODPYTHON-97) mod_python.publisher iterables and content_type broken
[ http://issues.apache.org/jira/browse/MODPYTHON-97?page=all ]
Nicolas Lehuen resolved MODPYTHON-97:
-
Fix Version: 3.2
Resolution: Fixed
Assign To: Nicolas Lehuen
Fixed this by reverting the changes from MODPYTHON-15.
mod_python.publisher iterables and content_type broken
--
Key: MODPYTHON-97
URL: http://issues.apache.org/jira/browse/MODPYTHON-97
Project: mod_python
Type: Bug
Components: publisher
Versions: 3.2
Reporter: Graham Dumpleton
Assignee: Nicolas Lehuen
Fix For: 3.2
In 3.2, mod_python.publisher was modified so that if it encountered an
interable it would recursively iterate over the items and publish each with
the result being concatenated.
FWIW, I personally didn't like this as I saw it potentially changing the
behaviour of existing code, although perhaps in contrived cases or for test
code only. I saw that this sort of behaviour should have been managed by the
user by explicit use of a wrapper class instead, rather than it being magic.
End of ramble. :-)
Regardless of my concerns, the behaviour that was added is broken.
Specifically, mod_python.publisher is setting the content type based on the
content of the first item returned from the iterable. For example, consider
the following:
index = [
'htmlbodyp',
1000 * X,
'/p/body/html',
]
When published, this is resulting in the content type being set to
'text/plain' and not 'text/html'. In part this is perhaps caused by the fact
that the content type check is now performed by looking for a trailing
'/html' in the content whereas previously it would look for a leading
'html'. This was changed because all the HTML prologue that can appear
before 'html' would often throw out this check with the HTML not being
automatically being detected. Thus at the time it was thought that looking
for the trailing '/html' would be more reliable. It ain't going to help to
go back to using a leading 'html' check though as the first item may only
contain the prologue and not 'html'.
These checks are only going to work for iterables if the results of
publishing of each item were added to the end of a list of strings, rather
than being written back immediately using req.write(). Once all that has been
returned by the iterable is obtained, this can all be joined back together
and then the HTML check done.
Joining all the separate items returned from the iterable back together
defeats the purpose of what this feature was about in the first place and may
result in huge in memory objects needing to be created to hold the combined
result just so the HTML check can be done.
The only way to avoid the problem is for the content type to be set
explicitly by the user before the iterable is processed. This is a bit tricky
as it is mod_python.publisher which is automagically doing this. The best you
can do is something like:
class SetContentType:
def __init__(self,content_type):
self.__content_type = content_type
def __call__(self,req):
req.content_type = self.__content_type
return
index = [
SetContentType('text/html'),
'htmlbodyp',
1000 * X,
'/p/body/html',
]
Once you start doing this, the user may as well have provided their own
published function in the first place that set the content type and manually
iterated over items and wrote them to req.write(). This could also be managed
by a user specified wrapper class which is how I saw this as preferably being
done in the first place. Ie.,
class PublishIterable:
def __init__(self,value,content_type):
self.__value = value
self.__content_type = content_type
def __call__(self,req):
req.content_type = self.__content_type
for item in self.__value:
req.write(item)
_values = [
'htmlbodyp',
1000 * X,
'/p/body/html',
]
index = PublishIterable(_values,'text/html')
Personally I believe this automagic publishing of iterables should be removed
from mod_python.publisher. You might still provide a special function/wrapper
that works like PublisherIterable but handles recursive structures and
callable objects in the process, but I feel it should be up to the user to
make a conscious effort to use it and mod_python.publisher shouldn't assume
that it should process any iterable in this way automatically.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (MODPYTHON-15) Publisher : iterable return values should be corretly published
[ http://issues.apache.org/jira/browse/MODPYTHON-15?page=all ]
Nicolas Lehuen reopened MODPYTHON-15:
-
Reopened to fix MODPYTHON-97.
Publisher : iterable return values should be corretly published
---
Key: MODPYTHON-15
URL: http://issues.apache.org/jira/browse/MODPYTHON-15
Project: mod_python
Type: Improvement
Versions: 3.1.3
Reporter: Nicolas Lehuen
Assignee: Nicolas Lehuen
Priority: Minor
Fix For: 3.2
Suppose this function in a published module :
def index(req)
req.content_type = 'text/plain'
yield '1\n'
yield '2\n'
yield '3\n'
yield '4\n'
When published, this module should return a text content with '1\n2\n3\n4\n'.
This could also be useful with a file() object, since they are iterable ;
this would provide another way to send a file, only slightly less performing
than the send_file() method. Handy when you want to filter a file :
def filter(req,filename):
f = open(filename,'r')
for line in f:
yield re.sub('foo','bar',line)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-99) accessing some request or server object members causes a segfault
[ http://issues.apache.org/jira/browse/MODPYTHON-99?page=comments#action_12360041 ] Nicolas Lehuen commented on MODPYTHON-99: - Modifying util.c so that tuple_from_array_header and tuple_from_method_list return an empty tuple instead of None fixes the problem, but I still have t(o check whether this change won't break anything else. accessing some request or server object members causes a segfault - Key: MODPYTHON-99 URL: http://issues.apache.org/jira/browse/MODPYTHON-99 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Jim Gallacher Priority: Critical Attachments: md-20051209.diff Martin Devara discovered a segfault when accessing some request object members. For example: def handler(req): req.content_type = text/plain req.write(EE\n) a = getattr(req,allowed_methods); return apache.OK Futher investigation revealed problems with several getter functions in requestobject.c and serverobject.c. The root of the problem seems to be pointer dereferencing errors in the getter code. The affected functions and the members which use them are: src/requestobject.c getreq_rec_ml allowed_methods getreq_rec_ah content_languages allowed_xmethods src/serverobject.c getsrv_recmbr_ah names wild_names Martin has provided a patch to fix the bug. (Thanks to Martin for tracking this down and providing the fix.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-99) accessing some request or server object members causes a segfault
[ http://issues.apache.org/jira/browse/MODPYTHON-99?page=comments#action_12360042 ] Nicolas Lehuen commented on MODPYTHON-99: - OK, if we modify tuple_from_array_header and tuple_from_method_list, here are the members that would be defined as an empty tuple rather than a None value when the underlying Apache data is not defined : server.names server.wildnames req.allowed_xmethods req.allowed_methods req.content_languages I don't know if we should change the behaviour of those members or simply alter the unit tests, though. accessing some request or server object members causes a segfault - Key: MODPYTHON-99 URL: http://issues.apache.org/jira/browse/MODPYTHON-99 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Jim Gallacher Priority: Critical Attachments: md-20051209.diff Martin Devara discovered a segfault when accessing some request object members. For example: def handler(req): req.content_type = text/plain req.write(EE\n) a = getattr(req,allowed_methods); return apache.OK Futher investigation revealed problems with several getter functions in requestobject.c and serverobject.c. The root of the problem seems to be pointer dereferencing errors in the getter code. The affected functions and the members which use them are: src/requestobject.c getreq_rec_ml allowed_methods getreq_rec_ah content_languages allowed_xmethods src/serverobject.c getsrv_recmbr_ah names wild_names Martin has provided a patch to fix the bug. (Thanks to Martin for tracking this down and providing the fix.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-99) accessing some request or server object members causes a segfault
[ http://issues.apache.org/jira/browse/MODPYTHON-99?page=comments#action_12360048 ] Jim Gallacher commented on MODPYTHON-99: The req.allowed_xmethods, req.allowed_methods documentation states that these are a tuples. It seems req.content_languages, server.names, server.wild_names are undocumented. I don't have mod_python 3.1.4 handy to test but certainly the relavent code has not changed since then. If the problem existed there then I don't think we need to worry about changing the return type since nobody would have been able to access these members anyway. accessing some request or server object members causes a segfault - Key: MODPYTHON-99 URL: http://issues.apache.org/jira/browse/MODPYTHON-99 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Jim Gallacher Priority: Critical Attachments: md-20051209.diff Martin Devara discovered a segfault when accessing some request object members. For example: def handler(req): req.content_type = text/plain req.write(EE\n) a = getattr(req,allowed_methods); return apache.OK Futher investigation revealed problems with several getter functions in requestobject.c and serverobject.c. The root of the problem seems to be pointer dereferencing errors in the getter code. The affected functions and the members which use them are: src/requestobject.c getreq_rec_ml allowed_methods getreq_rec_ah content_languages allowed_xmethods src/serverobject.c getsrv_recmbr_ah names wild_names Martin has provided a patch to fix the bug. (Thanks to Martin for tracking this down and providing the fix.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problem building httpd 2.0.55 with openssl 0.9.8a [FIXED but ...]
Stephen Collyer wrote: William A. Rowe, Jr. wrote: Stephen Collyer wrote: OK, I've found the problem and hacked a fix for it: [deleted] Did you run make install and point --with-ssl= at the install target, rather than a source build? I now understand what you mean here: did I do a make install of OpenSSL ? The answer is no, and this is what was screwing it up. All is well if OpenSSL is not only built, but installed. I didn't realise that the make install changed the dir structure, and I though I could get away with just a make. One caveat though - OpenSSL has to be configured with the shared argument e.g. ./config --prefix=/home/stephen/apache/openssl shared to ensure that the shared libs are built; the httpd 2.0.55 build fails otherwise. Thanks to Joe Orton for pointing out my error. (BTW, are problems in building Apache supposed to go this this list or the user list ?) -- Regards Stephen Collyer Netspinner Ltd
Re: AP_INIT_TAKE1 in 2.2 and C++
Thanks for the replies. The patch to ap_config.h that Joe Orton posted is reported to fix the problem. Can this be included in the next release? Cheers, --Phil.
monitor hook not working since 2.1.9?
I'm using Nick's hook monitor, called by ap_run_monitor() from mpm_common.c. It worked flawlessly under 2.1.4. It doesn't work with 2.1.9. Somewhere in the middle, between 2.1.4 and 2.1.9, something went wrong. It seems that ap_wait_or_timeout() was run at least once per a second under older versions, but not anymore. Does anybody know anything? Thanks -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: monitor hook not working since 2.1.9?
I'm not sure this is a problem; maybe only MY mistake. I'm still investigating. Meanwhile, please don't spend time for that. I wrote: I'm using Nick's hook monitor, called by ap_run_monitor() from mpm_common.c. It worked flawlessly under 2.1.4. It doesn't work with 2.1.9. Somewhere in the middle, between 2.1.4 and 2.1.9, something went wrong. It seems that ap_wait_or_timeout() was run at least once per a second under older versions, but not anymore. Does anybody know anything? Thanks -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On Sun, Dec 11, 2005 at 12:15:33AM -, [EMAIL PROTECTED] wrote: Author: rpluem Date: Sat Dec 10 16:15:27 2005 New Revision: 355823 URL: http://svn.apache.org/viewcvs?rev=355823view=rev Log: * Move handling of backends that broke after the headers have been sent into the proxy handler of mod_proxy. This patch still sets r-connection-aborted to 1 which is currently vetoed by Roy. Moving it from the scheme handler to the proxy handler should ease the reimplementation of this, as the scheme handlers only needs to return PROXY_BACKEND_BROKEN to signal the above situation to the proxy handler. Note that the previous code would return DONE to the core. This change drops that. As the code is written now, we're indicating to the core that more data can be written; which would be badness. -- justin
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On Dec 10, 2005, at 4:15 PM, [EMAIL PROTECTED] wrote:
Author: rpluem
Date: Sat Dec 10 16:15:27 2005
New Revision: 355823
URL: http://svn.apache.org/viewcvs?rev=355823view=rev
Log:
* Move handling of backends that broke after the headers have been
sent
into the proxy handler of mod_proxy.
This patch still sets r-connection-aborted to 1 which is currently
vetoed by Roy. Moving it from the scheme handler to the proxy
handler
should ease the reimplementation of this, as the scheme handlers
only
needs to return PROXY_BACKEND_BROKEN to signal the above
situation to
the proxy handler.
Oy, crikey, I don't want that -- the proxy handler doesn't have the
information needed to complete the response. As I said before, the
right way to do it is to send the error downstream. There is no
need to leave the filter in an error state.
As it turns out, we also have a request_rec-no_cache variable that
is supposed to be set in this case. I am curious whether the following
patch will work (after reverting r355823).
Roy
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 355728)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1481,12 +1481,16 @@
}
else if (rv != APR_SUCCESS) {
/* In this case, we are in real trouble
because
- * our backend bailed on us, so abort our
- * connection to our user too.
+ * our backend bailed on us.
*/
ap_log_cerror(APLOG_MARK, APLOG_ERR, rv, c,
proxy: error reading
response);
-c-aborted = 1;
+r-no_cache = 1;
+e = apr_bucket_eos_create(c-bucket_alloc);
+e-data = rv;
+APR_BRIGADE_INSERT_TAIL(bb, e);
+ap_pass_brigade(r-output_filters, bb);
+backend-close = 1;
break;
}
/* next time try a non-blocking read */
Index: modules/cache/mod_disk_cache.c
===
--- modules/cache/mod_disk_cache.c (revision 355728)
+++ modules/cache/mod_disk_cache.c (working copy)
@@ -1010,7 +1010,7 @@
* sanity checks.
*/
if (APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(bb))) {
-if (r-connection-aborted) {
+if (r-connection-aborted || r-no_cache) {
ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
disk_cache: Discarding body for URL %s
because connection has been aborted.,
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On Sat, Dec 10, 2005 at 04:51:22PM -0800, Roy Fielding wrote: Oy, crikey, I don't want that -- the proxy handler doesn't have the information needed to complete the response. As I said before, the right way to do it is to send the error downstream. There is no need to leave the filter in an error state. As it turns out, we also have a request_rec-no_cache variable that is supposed to be set in this case. I am curious whether the following patch will work (after reverting r355823). That will get mod_cache not to pick up on it, right. However, it won't force the connection to close. Or, give anything a chance to close it: be it HTTP/1.1 or Waka. =) -- justin
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On Dec 10, 2005, at 5:02 PM, Justin Erenkrantz wrote: That will get mod_cache not to pick up on it, right. However, it won't force the connection to close. Or, give anything a chance to close it: be it HTTP/1.1 or Waka. =) -- justin Right, that was just the proxy part -- the other half is not done yet. Roy
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On Sat, Dec 10, 2005 at 05:06:42PM -0800, Roy Fielding wrote: On Dec 10, 2005, at 5:02 PM, Justin Erenkrantz wrote: That will get mod_cache not to pick up on it, right. However, it won't force the connection to close. Or, give anything a chance to close it: be it HTTP/1.1 or Waka. =) -- justin Right, that was just the proxy part -- the other half is not done yet. Then, yes, +1 to that part. -- justin
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On 12/11/2005 01:51 AM, Roy T. Fielding wrote: On Dec 10, 2005, at 4:15 PM, [EMAIL PROTECTED] wrote: Oy, crikey, I don't want that -- the proxy handler doesn't have the information needed to complete the response. As I said before, the right way to do it is to send the error downstream. There is no need to leave the filter in an error state. As it turns out, we also have a request_rec-no_cache variable that is supposed to be set in this case. I am curious whether the following patch will work (after reverting r355823). But with your approach you need to double the code in *each* scheme handler. r355823 tries to avoid this by doing it a little later in the proxy handler. I currently comment only on the position *where* you do it and not what. But of course in the proxy handler I do not have rv add hand any longer. The remaining part of the patch could be done also in the proxy handler with e-data set to an int that is non null. Ok. Other approach would be to put your code in a function of proxy_util.c where every scheme handler can call it. That sounds also like a good solution. Regards Rüdiger
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On 12/11/2005 02:02 AM, Justin Erenkrantz wrote: On Sat, Dec 10, 2005 at 04:51:22PM -0800, Roy Fielding wrote: As it turns out, we also have a request_rec-no_cache variable that is supposed to be set in this case. I am curious whether the following patch will work (after reverting r355823). Reverted in the meantime. That will get mod_cache not to pick up on it, right. However, it won't force the connection to close. Or, give anything a chance to close it: be it HTTP/1.1 or Waka. =) -- justin What if we set c-keepalive to AP_CONN_CLOSE? I think mod_disk_cache should do the right thing with Roy's patch. The only thing that bugs me is that this check is done in mod_disk_cache and not in mod_cache. But this is independant from Roy's patch. I guess only the store_body function of the provider knows what things need to be done in this situation for this provider. So currently I see no chance to handle this generically in mod_cache :/. Regards Rüdiger
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On Dec 10, 2005, at 5:30 PM, Ruediger Pluem wrote:
But with your approach you need to double the code in *each* scheme
handler.
mod_mem_cache doesn't look like it works right now. I haven't looked
at the other schemes yet.
r355823 tries to avoid this by doing it a little later in the proxy
handler.
I currently comment only on the position *where* you do it and not
what.
But of course in the proxy handler I do not have rv add hand any
longer.
The remaining part of the patch could be done also in the proxy
handler
with e-data set to an int that is non null.
Ok. Other approach would be to put your code in a function of
proxy_util.c
where every scheme handler can call it. That sounds also like a
good solution.
Ideally it would be in APR, but that runs into version problems. Since
it is a general streams issue, I would put the function in httpd.h, but
right now I just want to know if it works at all (since I have no way
of testing it).
I think this is the full patch, but there may be a better place to
check for EOS errors.
Roy
Index: server/core_filters.c
===
--- server/core_filters.c (revision 355728)
+++ server/core_filters.c (working copy)
@@ -678,6 +678,11 @@
for (i = offset; i nvec; ) {
apr_bucket *bucket = APR_BRIGADE_FIRST(bb);
if (APR_BUCKET_IS_METADATA(bucket)) {
+if (APR_BUCKET_IS_EOS(bucket) bucket-data) {
+/* stream aborted and we have not ended it
yet */
+c-keepalive = AP_CONN_CLOSE;
+bucket-data = NULL;
+}
APR_BUCKET_REMOVE(bucket);
apr_bucket_destroy(bucket);
}
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 355728)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1481,12 +1481,16 @@
}
else if (rv != APR_SUCCESS) {
/* In this case, we are in real trouble
because
- * our backend bailed on us, so abort our
- * connection to our user too.
+ * our backend bailed on us.
*/
ap_log_cerror(APLOG_MARK, APLOG_ERR, rv, c,
proxy: error reading
response);
-c-aborted = 1;
+r-no_cache = 1;
+e = apr_bucket_eos_create(c-bucket_alloc);
+e-data = rv;
+APR_BRIGADE_INSERT_TAIL(bb, e);
+ap_pass_brigade(r-output_filters, bb);
+backend-close = 1;
break;
}
/* next time try a non-blocking read */
Index: modules/cache/mod_disk_cache.c
===
--- modules/cache/mod_disk_cache.c (revision 355728)
+++ modules/cache/mod_disk_cache.c (working copy)
@@ -1010,7 +1010,7 @@
* sanity checks.
*/
if (APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(bb))) {
-if (r-connection-aborted) {
+if (r-connection-aborted || r-no_cache) {
ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
disk_cache: Discarding body for URL %s
because connection has been aborted.,
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On 12/11/2005 02:49 AM, Roy T. Fielding wrote: On Dec 10, 2005, at 5:30 PM, Ruediger Pluem wrote: But with your approach you need to double the code in *each* scheme handler. mod_mem_cache doesn't look like it works right now. I haven't looked at the other schemes yet. I was talking about the proxy scheme handlers :-). mod_proxy_ajp currently has the same problem that we are trying to fix in mod_proxy_http [..cut..] Ideally it would be in APR, but that runs into version problems. Since it is a general streams issue, I would put the function in httpd.h, but And where do you want to put the code? Or do you want to make it a macro? right now I just want to know if it works at all (since I have no way of testing it). I hope Brian can step in and test it. Meanwhile I will have a look, if I can do a test. For ease of testing: Could you please resent the mail with the patch as attachment? BTW: Where is the extension of the request_rec structure? And isn't it a problem to change this structure in a stable branch, if we want to backport this fix? Regards Rüdiger
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On Sat, Dec 10, 2005 at 05:49:10PM -0800, Roy Fielding wrote:
+if (APR_BUCKET_IS_EOS(bucket) bucket-data) {
+/* stream aborted and we have not ended it
yet */
+c-keepalive = AP_CONN_CLOSE;
+bucket-data = NULL;
+}
The connection is still kept open rather than being closed. I can step
through a trace with you if you like. -- justin
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On 12/11/2005 03:12 AM, Justin Erenkrantz wrote:
On Sat, Dec 10, 2005 at 05:49:10PM -0800, Roy Fielding wrote:
+if (APR_BUCKET_IS_EOS(bucket) bucket-data) {
+/* stream aborted and we have not ended it
yet */
+c-keepalive = AP_CONN_CLOSE;
+bucket-data = NULL;
+}
The connection is still kept open rather than being closed. I can step
through a trace with you if you like. -- justin
Hm. But why? Once we have returned from ap_process_request
ap_process_http_connection
is left and the connection should be closed by the mpm.
Regards
Rüdiger
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On 12/11/2005 03:03 AM, Ruediger Pluem wrote: [..cut..] BTW: Where is the extension of the request_rec structure? And isn't it a problem to change this structure in a stable branch, if we want to backport this fix? Sorry my fault. I got the impression that no_cache needed to be added to the request_rec, but it is already there :-). Regards Rüdiger
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
On 12/11/2005 02:49 AM, Roy T. Fielding wrote:
On Dec 10, 2005, at 5:30 PM, Ruediger Pluem wrote:
[..cut..]
Ideally it would be in APR, but that runs into version problems. Since
it is a general streams issue, I would put the function in httpd.h, but
right now I just want to know if it works at all (since I have no way
of testing it).
Although I would like Brian to do a final test, it seems to work. I reverse
proxied to a Tomcat running the following jsp:
%@ page import=java.util.Date%%
Date datum;
datum = new Date();
response.setDateHeader(Expires,datum.getTime()+6);
%
html
head
title
Test
/title
/head
body
Startbr/
%
long i;
for (i=0; i 1; i++) {
%
testbr/
%
out.flush();
Thread.sleep(100);
}
%
Finishbr/
/html
via
ProxyPass /test balancer://mycluster/test stickysession=JSESSIONID nofailover=On
Proxy balancer://mycluster
BalancerMember http://127.0.0.1:8080 route=test
/Proxy
And just killed the Tomcat via kill -9 before the answer was complete.
httpd correctly discards the content cached so far now.
Regards
Rüdiger
[..cut..]
