[PATCH] Style police work on server/config.c
Hi, Patch is attached to prevent line wrapping/munging. I encountered this: Line 396: return !!(cmd-limited (AP_METHOD_BIT methnum)); ^^ Is that a typo or intentional? Sander config.patch Description: Binary data
RE: [PATCH] Style police work on server/config.c
From: Sander Striker [mailto:[EMAIL PROTECTED]] Sent: 05 March 2002 11:42 Hi, Patch is attached to prevent line wrapping/munging. I encountered this: Line 396: return !!(cmd-limited (AP_METHOD_BIT methnum)); ^^ Is that a typo or intentional? I also forgot to mention that there are some FIXME:s left in the code. Anyone care to take a look? Sander
[PATCH] server/connection.c detab
Hi, More formatting/style/readability stuff. Patch attached yadda yadda yadda. Sander connection.patch Description: Binary data
[PATCH] server/error_bucket.c detab
Hi, More detab. Patch attached Sander error_bucket.patch Description: Binary data
[PATCH] server/gen_test_char.c detab
Hi, Yet more detab. Patch attached. Sander gen_test_char.patch Description: Binary data
[PATCH] server/listen.c detab
Hi, More detab, etc. Can this go? Was there a future purpose to this call, or was it old code commented out? Line 320: /*free(lr);*/ Patch attached. Sander listen.patch Description: Binary data
Re: apr_file_open() and caching file descriptors
At 05:29 PM 3/4/2002, you wrote: On Mon, 4 Mar 2002, Bill Stoddard wrote: Rather than an option to not register a cleanup, perhaps a function to kill the cleanup would be more generally useful. apr_file_kill_cleanups(apr_file_t *file); You still have a problem with the apr_file_t disappearing when r-pool goes away, meaning you'd still need the apr_os_file_get/put thing, which just doesn't seem like a good idea to me. There has got to be a good way to do this... I'll keep thinking on it and get back to you asap. Caching introduces tons o' headaches. You won't like it, but you need a cross process cache pool derived from process-pool. Nahhh, don't need cross process squat. If you are interested in cross process caching, use mod_file_cache and preload the cache before the fork. I am completely not interested in generalizing mod_mem_cache to handle cross process caching at this point. Individual cache entries should each gain a subpool of their own ... if you do it right, the 'remove from cache' function is a cleanup of that subpool. And perhaps this is a good direction to look in. I originally discarded the thought until Cliff pointed out the APR_XTHREAD breakage if we do not maintain an apr_file_t. The subpool must be exactly the size needed to hold the apr_file_t (and perhaps slightly larger). Today, the size of the subpool is way to large... Bill
[PATCH] server/log.c detab
Hi, More detab, etc. Patch attached. Sander log.patch Description: Binary data
Re: Cannot build on LINUX PPC
Christian Gross wrote: Now here is another question What do all of you use as a development tool? gcc, gdb, and vi Jeff keeps telling me I should learn emacs, but I'm a bass player and we're notoriously slow Greg
Re: Weird network problem with MPM_WORKER
Pier Fumagalli [EMAIL PROTECTED] writes: Jeff Trawick [EMAIL PROTECTED] wrote: The Solaris fixes were required to fix a hang in getaddrinfo(). Yeah, looked at the archive and patched the whole baby before posting... Didn't change the behavior... When I had the same symptom as Pier mentions above, the fix was to get my IPv6 configuration straightened out. None of my network interfaces had IPv6 addresses, so attempting to connect to :: (in6addr_any) resulted in ENETUNREACH. Haha! :) Gotcha. So it's an IPv6 problem :) I don't have anything configured in IPv6 ATM, so that might be as well my problem... I'll try to figure out how to configure those, but at the same time, it would be cool to have in the autoconf for httpd a placeholder for --disable-ipv6 in autoconf for APR (if that solves the problem, will try!) by placeholder... you mean something like this? AC_ARG_ENABLE(ipv6, [ --disable-ipv6 Disable IPv6 support in APR and Apache] ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
detab before or after bucket changes? Re: [PATCH]server/error_bucket.c detab
Sander Striker wrote: Hi, More detab Patch attached Sander I have only one reservation about this series of detab patches: they'll break the one big pending change that I know of: Cliff's bucket free list diffs It might be easier to get the bucket free list changes applied first, and then change the formatting Cliff, any thoughts on the relative timing? --Brian
[dennis.lundberg@mdh.se: config/10040: Wrong file suffix for Swedish languge documents]
This bug report has come up before. Anyone mind if I commit a change to 1.3 to fix this? -aaron - Forwarded message from Dennis Lundberg [EMAIL PROTECTED] - From: Dennis Lundberg [EMAIL PROTECTED] Subject: config/10040: Wrong file suffix for Swedish languge documents To: [EMAIL PROTECTED] Date: 5 Mar 2002 14:04:24 - Reply-To: [EMAIL PROTECTED] Resent-Date: 5 Mar 2002 14:10:00 - Resent-Message-ID: [EMAIL PROTECTED] Resent-From: [EMAIL PROTECTED] (GNATS Filer) Resent-To: [EMAIL PROTECTED] Resent-Cc: [EMAIL PROTECTED] Resent-Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Number: 10040 Category: config Synopsis: Wrong file suffix for Swedish languge documents Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: apache Arrival-Date: Tue Mar 05 06:10:00 PST 2002 Closed-Date: Last-Modified: Originator: [EMAIL PROTECTED] Release:1.3.23 Organization: apache Environment: Solaris Description: We have done some tests using content-negotiation to supply documents in multiple languages, much like the index-page in the documentroot of a standard Apache installation. After reading the ISO spec for language- (639-1) and country-codes (3166) we have found that the config directives for mod_mime/AddLanguage seem to be wrong for some languages. The convention with different file suffices let the document author see what language a certain document is written in. The chosen file suffix for Swedish is .se which is identical to the country code, but the language code for Swedish is sv. In my opinion the file suffix should match the language and not the country, espcially for a language that is spoken in more than one country. I mean, you don't have a .us or .uk suffix for english. I believe that the same applies to Danish, which should be changed from .dk to .da. How-To-Repeat: Fix: *** httpd.conf-dist Tue Feb 19 11:27:10 2002 --- httpd.conf-dist.patch Tue Mar 5 14:45:06 2002 *** *** 748,754 AddLanguage ltz .lu AddLanguage ca .ca AddLanguage es .es ! AddLanguage sv .se AddLanguage cz .cz AddLanguage ru .ru AddLanguage zh-tw .tw --- 748,754 AddLanguage ltz .lu AddLanguage ca .ca AddLanguage es .es ! AddLanguage sv .sv AddLanguage cz .cz AddLanguage ru .ru AddLanguage zh-tw .tw Release-Note: Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, you need] [to include [EMAIL PROTECTED] in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as general/1098: or ] [Re: general/1098:). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] [apbugs address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ] - End forwarded message -
PATCH - mod_mime.c to allow broken modules with missing filename
I tried posting this patch February 4, but it must have gotten lost in the
shuffle of 2.0.32,
so here it is again. We found this with Tomcat.
In theme with the broken module being allowed to leave r-filename
as NULL in ap_directory_walk() and ap_file_walk(),
the find_ct() of mod_mime.c needs the following change
to allow a missing filename to pass through to the handlers. Otherwise
it will trip up on the r-filename.
I am pretty sure that DECLINED is the correct return, but I don't think
it matters.
Index: mod_mime.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/mod_mime.c
retrieving revision 1.76
--- mod_mime.cSat Dec 8 02:02:51 2001
+++ mod_mime.cMon Feb 4 09:30:46 2002
@@ -736,6 +736,14 @@
const char *fn, *type, *charset = NULL;
int found_metadata = 0;
+/* To allow broken modules to proceed, we allow missing filenames to
pass.
+ * We will catch it later if it's heading for the core handler.
+ * directory_walk already posted an INFO note for module debugging.
+ */
+if (!r-filename) {
+return DECLINED;
+}
+
if (r-finfo.filetype == APR_DIR) {
r-content_type = DIR_MAGIC_TYPE;
return OK;
Kent Bruinsma
[EMAIL PROTECTED]
Re: cvs commit: httpd-2.0/server core.c
Greg,
Please do not mix function change with code style changes.
Bill
gregames02/03/05 07:46:21
Modified:server core.c
Log:
fix Directory ~ blah containers.
also, eradicate a few nefarious tabs which were found lurking in the vicinity.
Submitted by: Rob Simonson [EMAIL PROTECTED]
Reviewed by: Greg Ames
Revision ChangesPath
1.157 +4 -3 httpd-2.0/server/core.c
Index: core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.156
retrieving revision 1.157
diff -u -r1.156 -r1.157
--- core.c 5 Mar 2002 05:24:21 - 1.156
+++ core.c 5 Mar 2002 15:46:21 - 1.157
@@ -1403,7 +1403,7 @@
}
AP_CORE_DECLARE_NONSTD(const char *) ap_limit_section(cmd_parms *cmd, void *dummy,
- const char *arg) {
+ const char *arg) {
const char *limited_methods = ap_getword(cmd-pool, arg, '');
void *tog = cmd-cmd-cmd_data;
apr_int64_t limited = 0;
@@ -1500,12 +1500,13 @@
cmd-override = OR_ALL|ACCESS_CONF;
if (!strcmp(cmd-path, ~)) {
- cmd-path = ap_getword_conf(cmd-pool, arg);
+cmd-path = ap_getword_conf(cmd-pool, arg);
if (!cmd-path)
return Directory ~ block must specify a path;
+r = ap_pregcomp(cmd-pool, cmd-path, REG_EXTENDED|USE_ICASE);
}
else if (thiscmd-cmd_data) { /* DirectoryMatch */
- r = ap_pregcomp(cmd-pool, cmd-path, REG_EXTENDED|USE_ICASE);
+r = ap_pregcomp(cmd-pool, cmd-path, REG_EXTENDED|USE_ICASE);
}
else if (!strcmp(cmd-path, /) == 0)
{
Re: the three filter types (was: cvs commit: httpd-2.0/servercore.c)
At 5:53 PM -0800 3/4/02, Greg Stein wrote: CONTENT: Filters of this type are valid for the time that this content is used to satisfy a request. For simple requests, this is identical to PROTOCOL, but internal redirects and sub-requests can change the content without ending the request. Just wanted to state that I believe Ryan has the correct distinction here -- that we have three types of filters. However, the third type is a misnomer, and we can derive the proper name from the HTTP model: resource Cool (on the above as well as the ideas for 2.1). I agree that RESOURCE is more clear. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
RE: [PATCH] server/core.c detab
The mail with the attachement bounced because it was 100k. If anyone wants it, please holler. It wasn't all simple find-replace, so better not wait until conflicts arise ;) Sander -Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED]] Sent: 05 March 2002 14:00 To: [EMAIL PROTECTED] Subject: [PATCH] server/core.c detab Hi, More detab and other style stuff. This time for server/core.c. I encountered this in there: Line 661: AP_DECLARE(const char *) ap_document_root(request_rec *r) /* Don't use this! */ If we shouldn't use it, why is it still here? And: Line 691: /* Should probably just get rid of this... the only code that cares is * part of the core anyway (and in fact, it isn't publicised to other * modules). */ Patch attached yadda yadda yadda. Sander
Problems writing a module
Title: Problems writing a module I've got serious problems with the cmd struct. When I try to use it, if I have a struct to fill (in this case named solconf) , I get garbage even if I try to let fields empty. And If i use a linked list, I cannot make the one for the request destroy when the request finish exec. And let me introduce something else: How do I get the data sent to me by a POST request in a form, from an apache module? well, that's all from now, and thanks in advance. Leonardo Belen. AFIP - Argentina.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
I disagree with this patch. If we are getting failures on locks
then we have a bug somewhere and I'd rather not see us cover up
the problem by decreasing the verbosity.
-aaron
On Tue, Mar 05, 2002 at 09:18:07PM -, [EMAIL PROTECTED] wrote:
trawick 02/03/05 13:18:07
Modified:server/mpm/worker worker.c
Log:
failures on the accept mutex are common at restart time, so be smart
about the log level and use APLOG_DEBUG if we're restarting
Revision ChangesPath
1.84 +14 -2 httpd-2.0/server/mpm/worker/worker.c
Index: worker.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/worker/worker.c,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- worker.c5 Mar 2002 21:01:24 - 1.83
+++ worker.c5 Mar 2002 21:18:07 - 1.84
@@ -622,7 +622,13 @@
if ((rv = SAFE_ACCEPT(apr_proc_mutex_lock(accept_mutex)))
!= APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_EMERG, rv, ap_server_conf,
+int level = APLOG_EMERG;
+
+if (ap_scoreboard_image-parent[process_slot].generation !=
+ap_scoreboard_image-global-running_generation) {
+level = APLOG_DEBUG; /* common to get these at restart time */
+}
+ap_log_error(APLOG_MARK, level, rv, ap_server_conf,
apr_proc_mutex_lock failed. Attempting to shutdown
process gracefully.);
signal_workers();
@@ -694,7 +700,13 @@
}
if ((rv = SAFE_ACCEPT(apr_proc_mutex_unlock(accept_mutex)))
!= APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_EMERG, rv, ap_server_conf,
+int level = APLOG_EMERG;
+
+if (ap_scoreboard_image-parent[process_slot].generation !=
+ap_scoreboard_image-global-running_generation) {
+level = APLOG_DEBUG; /* common to get these at restart time */
+}
+ap_log_error(APLOG_MARK, level, rv, ap_server_conf,
apr_proc_mutex_unlock failed. Attempting to
shutdown process gracefully.);
signal_workers();
Re: cvs commit: httpd-2.0 STATUS
On Tue, Mar 05, 2002 at 09:23:30PM -, [EMAIL PROTECTED] wrote: trawick 02/03/05 13:23:30 Modified:.STATUS Log: axe the entry on graceful restart problems with worker I was too stupid to read the code to determine that the accept mutex failure log messages were harmless and not indicative of a real problem. I'll try to understand the conditions where I'm seeing connections dropped. I suspect these are one and the same problem. When we get a failure while trying to acquire a mutex it probably means that the mutex was already destroyed. Is it possible that we also destroyed the fdqueue while there were connections waiting to be picked up by a worker? -aaron
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Aaron Bannert [EMAIL PROTECTED] writes: I disagree with this patch. If we are getting failures on locks then we have a bug somewhere and I'd rather not see us cover up the problem by decreasing the verbosity. Here is the sequence of events: 1) a thread in child process A is waiting on semaphore 2) graceful restart triggered 3) parent process cleans up the semaphore 4) that thread in child process A gets a failure (EIDRM) from the semaphore obtain and gracefully brings down other threads in child process A Normally in step 4 we'd get a high-severity log message. I changed the code to set the severity to debug since everything is working as designed. The process isn't going away prematurely, threads with active connections have a chance to finish serving the connection, etc. A variation on the sequence above is 1) a thread in child process B holds the semaphore and is blocked in poll() 2) graceful restart triggered 3) parent process cleans up semaphore and wakes up children 4) that thread in child process B returns from poll() and gets a failure from the semaphore release and tries to gracefully bring down other threads in child process B As with the previous scenario, everything is working fine. There is no sense having a high-priority log message about an expected condition. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote: Here is the sequence of events: 1) a thread in child process A is waiting on semaphore 2) graceful restart triggered 3) parent process cleans up the semaphore 4) that thread in child process A gets a failure (EIDRM) from the semaphore obtain and gracefully brings down other threads in child process A My point is that #3 and #4 are in the wrong order There should be nobody waiting on a semaphore when the parent cleans it up Normally in step 4 we'd get a high-severity log message I changed the code to set the severity to debug since everything is working as designed The process isn't going away prematurely, threads with active connections have a chance to finish serving the connection, etc A variation on the sequence above is 1) a thread in child process B holds the semaphore and is blocked in poll() 2) graceful restart triggered 3) parent process cleans up semaphore and wakes up children 4) that thread in child process B returns from poll() and gets a failure from the semaphore release and tries to gracefully bring down other threads in child process B As with the previous scenario, everything is working fine There is no sense having a high-priority log message about an expected condition Again, same problem The children should all be gone by the time the parent cleans up the semaphore The POD should ensure that nobody is sitting in poll, since the single listener will wake up and read from the POD, signal all siblings to die, and then release the semaphore -aaron
Re: cvs commit: httpd-2.0 STATUS
Aaron Bannert [EMAIL PROTECTED] writes: On Tue, Mar 05, 2002 at 09:23:30PM -, [EMAIL PROTECTED] wrote: trawick 02/03/05 13:23:30 Modified:.STATUS Log: axe the entry on graceful restart problems with worker I was too stupid to read the code to determine that the accept mutex failure log messages were harmless and not indicative of a real problem. I'll try to understand the conditions where I'm seeing connections dropped. I suspect these are one and the same problem. What do you mean by these? When we get a failure while trying to acquire a mutex it probably means that the mutex was already destroyed. Is it possible that we also destroyed the fdqueue while there were connections waiting to be picked up by a worker? worker threads exit as soon as workers_may_exit is set... I don't see any logic to make sure we don't lose any accepted connections (stuff in the queue) so yes, it looks normal to destroy worker_queue without looking to see if any accepted connections are in the queue Once the listener thread realizes that we're terminating and it will no longer call accept, it needs some way to trigger an error on the queue so that once the last connection is dequeued by a worker thread subsequent pop operations fail in a way that worker treads know they should exit. And instead of exiting as soon as workers_may_exit is set, worker threads should exit once they get the magic queue-is-dead error from a pop operation. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Aaron Bannert [EMAIL PROTECTED] writes: On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote: Here is the sequence of events: 1) a thread in child process A is waiting on semaphore 2) graceful restart triggered 3) parent process cleans up the semaphore 4) that thread in child process A gets a failure (EIDRM) from the semaphore obtain and gracefully brings down other threads in child process A My point is that #3 and #4 are in the wrong order. There should be nobody waiting on a semaphore when the parent cleans it up. For a graceful restart, the parent can't wait around for all children to go away before it cleans up and gets the next generation started. It needs to let worker threads in the old children die gradually as they finish processing active connection. That process can take a long time. (I thought about not cleaning up the semaphore at restart time, but Greg pointed out that doing so doesn't allow the admin to change the AcceptMutex foo setting without bringing down the server.) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Tue, Mar 05, 2002 at 05:07:38PM -0500, Jeff Trawick wrote: Aaron Bannert [EMAIL PROTECTED] writes: On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote: Here is the sequence of events: 1) a thread in child process A is waiting on semaphore 2) graceful restart triggered 3) parent process cleans up the semaphore 4) that thread in child process A gets a failure (EIDRM) from the semaphore obtain and gracefully brings down other threads in child process A My point is that #3 and #4 are in the wrong order. There should be nobody waiting on a semaphore when the parent cleans it up. For a graceful restart, the parent can't wait around for all children to go away before it cleans up and gets the next generation started. It needs to let worker threads in the old children die gradually as they finish processing active connection. That process can take a long time. Will they actually hold the semaphore while they are servicing long-lived connections? I guess we'd have to make it so that as soon as that worker* is done with that connection it checks to see if it is time to quit w/o hitting the semaphore again. Would that work? It still seems weird to me that we're essentially ignoring accept mutex errors during graceful. *worker meaning the smallest execution unit required to process a request, defined per-MPM. (I thought about not cleaning up the semaphore at restart time, but Greg pointed out that doing so doesn't allow the admin to change the AcceptMutex foo setting without bringing down the server.) Yeah, that sounds reasonable to me. -aaron
Re: apr_file_open() and caching file descriptors
Haven't had much time to think about this today, but I did discover that the XTHREAD support in win32 apr_file io is seriously broken. apr_file_open(APR_XTHREAD) on Windows should -not- be creating the overlapped structure and the io completion event. If an open file is being shared across thread, each thread should have it's own instance of apr_file_t with its own instance of the overlapped structure and the completion event. As it is now, if two threads both try to read from a file opened for overlapped i/o at the same time, thread 1 might get the io completion notification for the io issued by thread 2 or visa-versa. Not good. Bill On Mon, 4 Mar 2002, Bill Stoddard wrote: apr_file_open(yadda,..., APR_XTHREAD|APR_DO_NOT_REGISTER_CLEANUP, r-pool); I don't conceptually have a problem with the APR_NO_CLEANUP flag (or whatever it would be called), but I do have a problem with using apr_os_file_get/apr_os_file_put for this. There has got to be a better way. (For one thing, your APR_XTHREAD flag is meaningless if you do that.) Rather than an option to not register a cleanup, perhaps a function to kill the cleanup would be more generally useful. apr_file_kill_cleanups(apr_file_t *file); You still have a problem with the apr_file_t disappearing when r-pool goes away, meaning you'd still need the apr_os_file_get/put thing, which just doesn't seem like a good idea to me. There has got to be a good way to do this... I'll keep thinking on it and get back to you asap. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: AddOutputFilterByType
On Tue, Mar 05, 2002 at 07:04:43AM -0800, Ryan Bloom wrote: Why is this thing being run in the fixups phase? The whole point of the insert_filters phase is to insert filters for the given resource Why are we trying to insert resource based filters in the fixups? Especially given that the resource can change during the fixups phase True, this is where OtherBill suggested to me where it should go But now that I understand our filtering hooks a bit better, I now agree that insert_filter makes more sense However, should we attempt to abstract setting r-content_type so that we can intercept whenever the content_type is modified and add the right filters as dictated by AddOutputFilterByType? I have some reservations about that though, but it might solve our filter changing the content-type on us Also, why does mod_negotiation handle fixups in type_checker and mod_dir does it in fixups? I'd suggest that we should move the handle_multi call to be a fixups so that we are consistent where our redirect calls occur -- justin
Re: AddOutputFilterByType
At 04:29 PM 3/5/2002, you wrote: Also, why does mod_negotiation handle fixups in type_checker and mod_dir does it in fixups? I'd suggest that we should move the handle_multi call to be a fixups so that we are consistent where our redirect calls occur -- justin Cut it out already :-) We don't know if some other module is -interested- in that dir so mod_dir will wait till fixups to say hey - I can do that! and auth is run for the dir as well as its indexhtml Negotiation decides way up in type_checker that yea - that's a multiview, and this is what we will do with it Rbb and I chatted about this earlier today It seems like once the decision is reached that we have a fast internal redirect, we should _stop_ processing that main request Obviously some well defined return value from the hook fn, similar to DONE but not quite the same What would be most cool is to set an r-replace_request member to the subrequest we will run Then in the run request phase, look at replace_request and run the insert_filters/run_handler against that replacement Need to spend 2 hours away from work + apache I'll check in later and see if the solution is really that trivial Bill
Re: apr_file_open() and caching file descriptors
Will submit a patch later on this evening... Bill - Original Message - From: Bill Stoddard [EMAIL PROTECTED] To: Cliff Woolley [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; APR Development List [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 5:24 PM Subject: Re: apr_file_open() and caching file descriptors Haven't had much time to think about this today, but I did discover that the XTHREAD support in win32 apr_file io is seriously broken. apr_file_open(APR_XTHREAD) on Windows should -not- be creating the overlapped structure and the io completion event. If an open file is being shared across thread, each thread should have it's own instance of apr_file_t with its own instance of the overlapped structure and the completion event. As it is now, if two threads both try to read from a file opened for overlapped i/o at the same time, thread 1 might get the io completion notification for the io issued by thread 2 or visa-versa. Not good. Bill On Mon, 4 Mar 2002, Bill Stoddard wrote: apr_file_open(yadda,..., APR_XTHREAD|APR_DO_NOT_REGISTER_CLEANUP, r-pool); I don't conceptually have a problem with the APR_NO_CLEANUP flag (or whatever it would be called), but I do have a problem with using apr_os_file_get/apr_os_file_put for this. There has got to be a better way. (For one thing, your APR_XTHREAD flag is meaningless if you do that.) Rather than an option to not register a cleanup, perhaps a function to kill the cleanup would be more generally useful. apr_file_kill_cleanups(apr_file_t *file); You still have a problem with the apr_file_t disappearing when r-pool goes away, meaning you'd still need the apr_os_file_get/put thing, which just doesn't seem like a good idea to me. There has got to be a good way to do this... I'll keep thinking on it and get back to you asap. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: AddOutputFilterByType
On Tue, Mar 05, 2002 at 04:43:50PM -0600, William A Rowe, Jr wrote: Cut it out already :-) I'll try Rbb and I chatted about this earlier today It seems like once the decision is reached that we have a fast internal redirect, we should _stop_ processing that main request Obviously some well defined return value from the hook fn, similar to DONE but not quite the same Ahem, wasn't I saying that? ;-) Yes, I think we need this too What would be most cool is to set an r-replace_request member to the subrequest we will run Then in the run request phase, look at replace_request and run the insert_filters/run_handler against that replacement That could be goodness I agree that I'm not sure if it is really that trivial Perhaps Well, actually, I know it won't be since some filters do different things when r-main is set I can see rbb saying, Those filters are broken Is that the case? -- justin
RE: AddOutputFilterByType
Rbb and I chatted about this earlier today It seems like once the decision is reached that we have a fast internal redirect, we should _stop_ processing that main request Obviously some well defined return value from the hook fn, similar to DONE but not quite the same Ahem, wasn't I saying that? ;-) Yes, I think we need this too What would be most cool is to set an r-replace_request member to the subrequest we will run Then in the run request phase, look at replace_request and run the insert_filters/run_handler against that replacement That could be goodness I agree that I'm not sure if it is really that trivial Perhaps Well, actually, I know it won't be since some filters do different things when r-main is set I can see rbb saying, Those filters are broken Is that the case? -- justin No that isn't the case, and the fix isn't that trivial It isn't impossible, but it adds an if to every single hook call Ryan
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Aaron Bannert [EMAIL PROTECTED] writes: On Tue, Mar 05, 2002 at 05:07:38PM -0500, Jeff Trawick wrote: Aaron Bannert [EMAIL PROTECTED] writes: On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote: Here is the sequence of events: 1) a thread in child process A is waiting on semaphore 2) graceful restart triggered 3) parent process cleans up the semaphore 4) that thread in child process A gets a failure (EIDRM) from the semaphore obtain and gracefully brings down other threads in child process A My point is that #3 and #4 are in the wrong order. There should be nobody waiting on a semaphore when the parent cleans it up. For a graceful restart, the parent can't wait around for all children to go away before it cleans up and gets the next generation started. It needs to let worker threads in the old children die gradually as they finish processing active connection. That process can take a long time. Will they actually hold the semaphore while they are servicing long-lived connections? no... the semaphore is held only during the poll+accept I guess we'd have to make it so that as soon as that worker* is done with that connection it checks to see if it is time to quit w/o hitting the semaphore again. Would that work? Current code doesn't try to obtain the semaphore again if it is time to go away. It still seems weird to me that we're essentially ignoring accept mutex errors during graceful. (shrug) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Tue, Mar 05, 2002 at 07:02:46PM -0500, Jeff Trawick wrote: Will they actually hold the semaphore while they are servicing long-lived connections? no the semaphore is held only during the poll+accept I guess we'd have to make it so that as soon as that worker* is done with that connection it checks to see if it is time to quit w/o hitting the semaphore again Would that work? Current code doesn't try to obtain the semaphore again if it is time to go away In that case, the mutex error is completely valid and we should be considering why the listener thread has not escaped from the accept loop when the POD told it to do so -aaron
Re: cvs commit: httpd-2.0 STATUS
On Tue, Mar 05, 2002 at 05:03:16PM -0500, Jeff Trawick wrote: axe the entry on graceful restart problems with worker I was too stupid to read the code to determine that the accept mutex failure log messages were harmless and not indicative of a real problem I'll try to understand the conditions where I'm seeing connections dropped I suspect these are one and the same problem What do you mean by these? I was referring to the dropped connections and the errors on mutex acquire When we get a failure while trying to acquire a mutex it probably means that the mutex was already destroyed Is it possible that we also destroyed the fdqueue while there were connections waiting to be picked up by a worker? worker threads exit as soon as workers_may_exit is set I don't see any logic to make sure we don't lose any accepted connections (stuff in the queue) so yes, it looks normal to destroy worker_queue without looking to see if any accepted connections are in the queue Once the listener thread realizes that we're terminating and it will no longer call accept, it needs some way to trigger an error on the queue so that once the last connection is dequeued by a worker thread subsequent pop operations fail in a way that worker treads know they should exit And instead of exiting as soon as workers_may_exit is set, worker threads should exit once they get the magic queue-is-dead error from a pop operation I would agree that this is a limitation of the current fdqueue logic and that it is a bug I had some code that did something similiar to what you were talking about, but it was related to a different worker implementtion variant If I get some time I'll try to take a look -aaron
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Aaron Bannert [EMAIL PROTECTED] writes: On Tue, Mar 05, 2002 at 07:02:46PM -0500, Jeff Trawick wrote: Will they actually hold the semaphore while they are servicing long-lived connections? no... the semaphore is held only during the poll+accept I guess we'd have to make it so that as soon as that worker* is done with that connection it checks to see if it is time to quit w/o hitting the semaphore again. Would that work? Current code doesn't try to obtain the semaphore again if it is time to go away. In that case, the mutex error is completely valid and we should be considering why the listener thread has not escaped from the accept loop when the POD told it to do so. I don't understand your concern. I've never seen a case where the listener thread doesn't escape from the accept loop. Sometimes it escapes before it checks the pod (because of a mutex error) but at least it escapes. --- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: the three filter types
On Mon, Mar 04, 2002 at 11:13:29PM -0600, William A Rowe, Jr wrote: At 07:53 PM 3/4/2002, you wrote: Just wanted to state that I believe Ryan has the correct distinction here -- that we have three types of filters However, the third type is a misnomer, and we can derive the proper name from the HTTP model: resource Resource, body, content, whichever In HTTP, it is a resource you're make a request against The body and content are aspects of the protocol (the message, in particular) The trick is that any 'resource' can be aggregated, while the connection filters are pretty fixed [or mutate in stable ways, such as connection:upgrade semantics], protocol filters are pretty fixed [they are designed by the top resource], The protocol is *not* defined by the resource It is defined by the underlying connection My client is connecting to the server with a particular protocol The resource that I talk to has *nothing* to do with that but we can munge together a bunch of 'resource' streams into one 'request' [as once defined in 13 :-] Yup For instance, a PROPFIND returning data from many resources (mod_dav defines a walk API over resources to do this) SSI allows you to incorporate multiple resources, but this is tricky ground There are public resources, and then there are resources that could be entirely private to the server (such as a CGI invoked only thru SSI, but it doesn't have a URL associated with it) The distinction could be important In HTTP, you talk to a resource on the server With our redirect stuff, all we're doing is pointing to a different resource The connection and protocol remain the same Bingo, for the most part Absolutely on when it comes to merging several resources [sub-requests] Only thing is that which resource will have some thing to do with the protocol (want the gz flavor? here it is) No, the protocol adjusts itself based on characteristics of the resource and what the client requested For example, with gz, the protocol sees the Accept-Encoding and turns on the compression But the protocl might also look at the resource's type and say, hmm it's a jpeg that isn't going to compress Point is: the resource is strictly hidden from protocol concerns In Apache 21, I'd like to move towards the resource model, and also create a resource mapping tree Rather than this whole location / directory walk crap, we navigate down a tree Each node identifies a different provider of resources The root node (/) refers to the filesystem provider, keyed in at DocumentRoot The Alias directive creates new nodes in the location tree, also referring to the filesystem provider, but they point to a different space in the filesystem etc etc You sort of describe what happened with map_to_storage directory only applies to surprise files :) I don't know if we can rip away Location altogether While it would be nice, Holy crap I'm not talking about taking out Location That is the whole key to the mechanism! You lay out your URL space (eg Location directives) into a tree in memory At each node, you hang configuration elements, a hash table pointing to child nodes, and a resource provider for that node and its children (of course, unless overridden by a provider statement below that point) the location concept gives us some high-level abstractions, such as auth contexts, etc, that are still relevant/useful But I would like to see us continue to 'discourage' their use in so far as users 'presumed' the two work the same URI space != file mounts :) I have never agreed with the concept of discouraging the Location directive The Location directives, and the implicit tree (namespace) it defines are how a user sees the site The Directory directive is looking at your server from the wrong direction Essentially, you lay out your URL space using Location and other directives which define locations (Alias, for example; it defines a location which maps to a directory) The Directory is then used to establish details about the underlying filesystem, but it is *totally* independent of the Location tree / subtree1/ subsub/ subtree2/ subthree/ The location tree might look like something above, and it has providers associated with different points on that tree Usually, it will be the default filesystem provider The filesystem provider has its own tree of configuration data, as applied to the content in the filesystem /home/www/docroot/ group1/ subsub/ subtree2/ group3/ The configuration associated with the Directory directive is stored in this tree, not in the Location tree When the system walks down the location tree to the target resource, it asks the provider for additional config (beyond what may be hooked into the location tree) That is where the filesystem provider can return the config associated with elements in its tree (based on whatever the Location node happened to map to in its tre) Much of this resource model
RE: AddOutputFilterByType
What would be most cool is to set an r-replace_request member to the subrequest we will run Then in the run request phase, look at replace_request and run the insert_filters/run_handler against that replacement That could be goodness I agree that I'm not sure if it is really that trivial Perhaps Well, actually, I know it won't be since some filters do different things when r-main is set I can see rbb saying, Those filters are broken Is that the case? -- justin No that isn't the case, and the fix isn't that trivial It isn't impossible, but it adds an if to every single hook call Or would it your griping about it [both of you] suddenly sparked some insight if the return code is != 0 then we test the various cases The mainline OK case remains unhindered :) Bill
Current CVS with PHP/CGI on Win32
Just built the current CVS of httpd-20 and ran into the following problem: I use PHP with httpd-20 through CGI and everything works fine with a httpd-20 from a week ago, or so Accessing a php file with the current CVS HEAD version of httpd-20 results in a ''download offer'' of the _parsed_ output of the script -- Sebastian Bergmann http://sebastian-bergmannde/ http://phpOpenTrackerde/ Did I help you? Consider a gift: http://wishlistsebastian-bergmannde/
Re: cvs commit: httpd-2.0/modules/http http_request.c
On Tue, Mar 05, 2002 at 05:41:28AM -, [EMAIL PROTECTED] wrote: rbb 02/03/04 21:41:28 Modified:modules/http http_request.c Log: Remove another hack from the server. The add_required_filters function was required to make sure that the sub request had the correct filters when we went send the error page. With the new filter insertion logic, this is no longer necessary. ... @@ -127,8 +105,6 @@ * to obtain the original error, but when adding the required_filters, * we need to do so against the one we came in with. So, save it. */ -request_rec *cur = r; - Looks like there is a comment sitting there that doesn't apply any more... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: the three filter types (was: cvs commit: httpd-2.0/server core.c)
On Mon, Mar 04, 2002 at 08:35:35PM -0800, Ryan Bloom wrote: On Sun, Mar 03, 2002 at 10:34:55PM -, [EMAIL PROTECTED] wrote: ... Just wanted to state that I believe Ryan has the correct distinction here -- that we have three types of filters. However, the third type is a misnomer, and we can derive the proper name from the HTTP model: resource YES, resource is markedly better than CONTENT. I have been using resource all day when explaining this to people at work. Always scary when Greg and I agree. :-) Oh, for christssakes... put up some kind of argument... ;-) -- Greg Stein, http://www.lyra.org/
