Re: mod_proxy_balancer / failover (hot standby)
On 02/28/2006 05:46 PM, [EMAIL PROTECTED] wrote: > Hello, > > I´d like to restart the thread > http://www.gossamer-threads.com/lists/apache/dev/305214 Thanks for starting this again. I also lost track of it. > > Please let me know if I just missed a correct config - otherwise I am curious > to hear what you think and if you perhaps can provide another fix...? No you did not miss the correct config. Currently it does not work without the patch attached somewhere in http://www.gossamer-threads.com/lists/apache/dev/305214 One further obstacle is that it seems to me that even with the patch it does not do a failover if you do not already have a session. So some broader changes are actually needed. I hope (and hoped) to get some feedback by other developers on this issue to clarify the definition of 'disabled'. Once this is done we can go into the details about how to implement this. Regards Rüdiger
Re: svn commit: r381758 - /httpd/httpd/trunk/docs/manual/howto/public_html.xml
On Tuesday 28 February 2006 19:47, [EMAIL PROTECTED] wrote: > +Note that, by default, access to these directories is > not +enabled. You can enable access when using > UserDir by commenting out > the line > + > + Include conf/extra/httpd-userdir.conf > + Huh? Enable it by commenting out that line? If that's right then the configuration is indeed confusing. -- Nick Kew
Re: return value of httpd
On Feb 28, 2006, at 8:23 AM, Brian Akins wrote: If I run httpd -k stop, if it cannot stop listener, it still returns 0. same for graceful-stop. should it return something else? Depends on what it actually does. If you follow the code into server/ main.c:630 and server/mpm_common.c:898, you see that all httpd -k stop does is send a SIGTERM to the pid read from the PidFile in the config. Its return value merely means "I've sent the signal" and not "httpd was successfully shut down" because there's no way it can know this. S. smime.p7s Description: S/MIME cryptographic signature
Re: [Bug 38070] - httpd returns status code 200 instead 304, but logged 304 in log.
On Wed, Feb 22, 2006 at 12:53:25PM +, Joe Orton wrote: > On Tue, Feb 21, 2006 at 03:45:39PM +, Nick Kew wrote: > > Not as such. It doesn't need to: it's a MUST in CGI: > > > > 7.2.1.3. Status > > The "Status" header field is used to indicate to the server what status > > code > > the server MUST use in the response message. > > > > Your patch breaks that, plain and simple. > > Given that the CGI spec does not cover conditional request processing I > don't think that's relevant. There will always be ways that the server > will override an explicit "Status: 200" - the byterange filter would do > it (before it was changed, for incidental reasons); mod_cgi will now do > it if a Location header is also sent, since Jeff has just fixed the real > r->status_line handling bug on the trunk. > > As Dave Sparks pointed out in the PR, any downstream HTTP proxy may turn > a conditional HTTP request into a 304, so it's not particularly useful > to allow the CGI script to force it at the origin. Any script which > relies on that particular behaviour is broken anyway, even if the CGI > spec is oblivious to that fact. If there's nothing else to discuss then given the above I'm -1 on the util_script.c r370692 change, the r379562 fix for r->status_line handling is the sufficient and correct way to fix PR 38070 (same goes for 2.[02].x). joe
mod_proxy_balancer / failover (hot standby)
Hello, I´d like to restart the thread http://www.gossamer-threads.com/lists/apache/dev/305214 Summary of that thread: Ruediger Plum fixed mod_proxy_balancer so that the status=d became persistent. (http://svn.apache.org/viewcvs?rev=374929&view=rev) Having applied the fix / using the following config..: ProxyPass / balancer://mycluster stickysession=SESSION_COOKIE BalancerMember http://192.168.4.2:80 route=a redirect=b BalancerMember http://192.168.4.3:80 route=b status=d ..the behaviour is the following (a little too persistent perhaps ;): After shutting down Member a, it gets status err, but member b stays disabled -> Apache returns error 503. I now have to remove the "status=d" for member b myself. The expected behaviour would have been: member b gets the requests as soon as member a is in error state. The thread (see link above) ended with Ruediger Plums questions and answers from Robby Pedrica: > > 1. What is the exact meaning of a disabled worker? Should it be considered > for use if find_best_worker cannot find a worker in non error mode and > nofailover > is set to off? > Should a redirected worker that is disabled be used? I´d say yes. Robby suggested a new type of status "stdby" to differenciate between standby and disabled. Sounds also good if people need that. > 2. What about chains of redirects (worker 'a' has a redirect to worker 'b', > worker 'b' has a redirect to worker 'c')? Considering hotstandby/failover only, I am not seeing a need to care about this. Looks like a different issue to me. Please let me know if I just missed a correct config - otherwise I am curious to hear what you think and if you perhaps can provide another fix...? Thanks and best regards, Andreas Dieses Dokument ist vertraulich und ausschliesslich fuer den Adressaten bestimmt. Falls Sie diese E-Mail versehentlich bekommen haben, informieren Sie uns bitte unverzueglich und loeschen Sie diese Nachricht von Ihrem Computer. Jegliche Art von Reproduktion, Verbreitung, Vervielfaeltigung, Modifikation, Verteilung und/oder Publikation dieser E-Mail Nachricht ist untersagt. Die in dieser E-Mail enthaltenen Angaben und Erklaerungen sind unverbindlich. Haftungsansprueche des Empfaengers jeglicher Art werden ausgeschlossen. Die GZS schliesst ausser fuer den Fall von Vorsatz oder grober Fahrlaessigkeit die Haftung fuer jeglichen Verlust oder Schaeden durch virenbefallene Software oder E-Mails aus. --- This message contains confidential information and is intended only for the named individual. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message in error and delete this e-message from your system. No reliance may be placed on this message without written confirmation of its contents from an authorized representative. GZS accepts no liability for loss or damage caused by software viruses except in case of gross negligence or willful behaviour.
Re: [PATCH] 2.2.x + apreq
Joe Schaefer <[EMAIL PROTECTED]> writes:
> Here's a patch against the 2.2.x branch of httpd (you need to
> apply the svn:externals properties manually). With it I can
> build mod_apreq (no 2) statically or dynamically. Haven't tested
> it at all yet tho.
Here's a better patch against httpd/branches/2.2.x which gives the
correct linkages on *nix.
Index: server/Makefile.in
===
--- server/Makefile.in (revision 380928)
+++ server/Makefile.in (working copy)
@@ -32,6 +32,7 @@
EXPORT_DIRS = $(top_srcdir)/include $(top_srcdir)/os/$(OS_DIR)
$(top_srcdir)/modules/http
EXPORT_DIRS_APR = $(APR_INCLUDEDIR) $(APU_INCLUDEDIR)
+EXPORT_DIRS_APREQ = $(APREQ_INCLUDEDIR)
# If export_files is a dependency here, but we remove it during this stage,
# when exports.c is generated, make will not detect that export_files is no
@@ -61,6 +62,9 @@
for dir in $(EXPORT_DIRS_APR); do \
(ls $$dir/ap[ru].h $$dir/ap[ru]_*.h >> $$tmp 2>/dev/null); \
done; \
+ for dir in $(EXPORT_DIRS_APREQ); do \
+ (ls $$dir/apreq.h $$dir/apreq_*.h >> $$tmp 2>/dev/null); \
+ done; \
sort -u $$tmp > $@; \
rm -f $$tmp
Property changes on: modules
___
Name: svn:externals
+ apreq
https://svn.apache.org/repos/asf/httpd/apreq/branches/apr-build-system/module/apache2
Property changes on: srclib
___
Name: svn:externals
+ apreq
https://svn.apache.org/repos/asf/httpd/apreq/branches/apr-build-system
Index: configure.in
===
--- configure.in(revision 380928)
+++ configure.in(working copy)
@@ -16,6 +16,7 @@
sinclude(build/apr_common.m4)
sinclude(build/find_apr.m4)
sinclude(build/find_apu.m4)
+sinclude(build/find_apreq.m4)
sinclude(acinclude.m4)
dnl XXX we can't just use AC_PREFIX_DEFAULT because that isn't subbed in
@@ -120,6 +121,30 @@
APU_VERSION=`$apu_config --version`
APU_CONFIG="$APU_BINDIR/apu-`echo ${APU_VERSION} | sed 's,\..*,,'`-config"
+echo $ac_n "${nl}Configuring Apache HTTP Server Request library ...${nl}"
+
+APR_FIND_APREQ("$srcdir/srclib/apreq", "./srclib/apreq", 1, 1)
+
+if test "$apreq_found" = "no"; then
+ AC_MSG_ERROR([APREQ not found. Please read the documentation.])
+fi
+
+if test "$apreq_found" = "reconfig"; then
+ APR_SUBDIR_CONFIG(srclib/apreq,
+[--with-apr=$apr_config --with-apr-util=$apu_config
--prefix=$prefix --exec-prefix=$exec_prefix --libdir=$libdir
--includedir=$includedir --bindir=$bindir],
+[--enable-layout=*|\'--enable-layout=*])
+ dnl We must be the last to build and the first to be cleaned
+ AP_BUILD_SRCLIB_DIRS="$AP_BUILD_SRCLIB_DIRS apreq"
+ AP_CLEAN_SRCLIB_DIRS="apreq $AP_CLEAN_SRCLIB_DIRS"
+fi
+
+APR_ADDTO(LDFLAGS, `$apreq_config --ldflags`)
+APREQ_BINDIR=`$apreq_config --bindir`
+APREQ_INCLUDEDIR=`$apreq_config --includedir`
+APREQ_VERSION=`$apreq_config --library-version`
+APREQ_CONFIG="$APREQ_BINDIR/apreq`echo ${APREQ_VERSION} | sed
's,\..*,,'`-config"
+
+
dnl In case we picked up CC and CPP from APR, get that info into the
dnl config cache so that PCRE uses it. Otherwise, CC and CPP used for
dnl PCRE and for our config tests will be whatever PCRE determines.
@@ -190,6 +215,7 @@
# directories.
APR_ADDTO(INCLUDES, `$apr_config --includes`)
APR_ADDTO(INCLUDES, `$apu_config --includes`)
+APR_ADDTO(INCLUDES, `$apreq_config --includes`)
echo $ac_n "${nl}Applying OS-specific hints for httpd ...${nl}"
@@ -564,7 +590,7 @@
AC_DEFINE_UNQUOTED(AP_SUEXEC_UMASK, 0$withval, [umask for suexec'd process]
) ] )
dnl APR should go after the other libs, so the right symbols can be picked up
-AP_LIBS="$AP_LIBS `$apu_config --link-libtool --libs` `$apr_config
--link-libtool --libs`"
+AP_LIBS="$AP_LIBS `$apu_config --link-libtool --libs` `$apr_config
--link-libtool --libs` `$apreq_config --link-libtool --libs`"
APACHE_SUBST(AP_LIBS)
APACHE_SUBST(AP_BUILD_SRCLIB_DIRS)
APACHE_SUBST(AP_CLEAN_SRCLIB_DIRS)
Index: build/make_nw_export.awk
===
--- build/make_nw_export.awk(revision 380928)
+++ build/make_nw_export.awk(working copy)
@@ -37,8 +37,8 @@
}
}
-/^[ \t]*AP([RU]|_CORE)?_DECLARE[^(]*[(][^)]*[)]([^ ]* )*[^(]+[(]/ {
-sub("[ \t]*AP([RU]|_CORE)?_DECLARE[^(]*[(][^)]*[)][ \t]*", "")
+/^[ \t]*AP([RU]|_CORE|REQ)?_DECLARE[^(]*[(][^)]*[)]([^ ]* )*[^(]+[(]/ {
+sub("[ \t]*AP([RU]|_CORE|REQ)?_DECLARE[^(]*[(][^)]*[)][ \t]*", "")
sub("[(].*", "")
sub("([^ ]* (^([ \t]*[(])))+", "")
@@ -79,7 +79,7 @@
next
}
-/^[ \t]*(extern[ \t]+)?AP[RU]?_DECLARE_DATA .*;$/ {
+/^[ \t]*(extern[ \t]+)?AP([RU]|REQ)?_DECLARE_DATA .*;$/ {
varname = $NF;
gsub( /[*;]/, "", varname);
gsub( /\[.*\]/, "", varname);
return value of httpd
If I run httpd -k stop, if it cannot stop listener, it still returns 0. same for graceful-stop. should it return something else? -- Brian Akins Lead Systems Engineer CNN Internet Technologies
RE: Problem with apr_time_exp_lt (localtime_r) on AIX
Lekha,
I wrote the sample program below, and ran it on both AIX
4.3.3 & AIX 5.1
in both threaded and unthreaded mode (xlc vs. xlc_r
compiler).
In both cases it returned 138.
#ifdef _THREAD_SAFE#include
#endif
#include #include
main(){
struct tm wk_localtime;
struct tm *my_localtime;
time_t my_time = 2147483647;
#ifdef _THREAD_SAFE
memset(&wk_localtime, '\0',
sizeof(wk_localtime)); my_localtime =
localtime_r(&my_time, &wk_localtime);
#else
my_localtime =
localtime(&my_time);
#endif
printf("my_localtime->tm_year=%hd\n",
my_localtime->tm_year);
}
From: Lekha Menon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 28, 2006 4:57 AMTo:
dev@httpd.apache.orgSubject: Problem with apr_time_exp_lt
(localtime_r) on AIX
Hi,
I am facing a strange problem with
apr_time_exp_lt.
On AIX, when i call apr_time_exp_lt with
2nd arg as 214748364700LL, it sets the yr as 1 instead on 138.
The same works on Linux
properly.
I investigated the code & found that
apr_time_exp_lt internally calls explode_time().
Here, localtime_r is called with arguments
(&tt, &tm) where tt=2147483647.
localtime_r seems to be having some
issue!
For checking localtime_r, i wrote a sample
program. There also, while passing tt=2147483647, it returned 1 instead of
138.
Is this AIX specific?
Please help!
Thanks in adv!
Regards,
Lekha
http://www.patni.comWorld-Wide Partnerships.
World-Class Solutions.
_
This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to whom this
message was originally addressed. Any review, e-transmission dissemination or
other use of or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If you have
received this e-mail in error kindly delete this e-mail from your records. If it
appears that this mail has been forwarded to you without proper authority,
please notify us immediately at [EMAIL PROTECTED] and delete this mail.
_
Re: httpd-trunk with MSIE (async read broken?) and AJP problems was Re: httpd-trunk sucking CPU on ajax
On Feb 27, 2006, at 11:42 AM, Ruediger Pluem wrote: Do we really have the async read code on trunk? Maybe I missed some commits, but I thought that we only have the async write stuff in the trunk. The trunk had the async write implementation plus a refactored version of the synchronous read code (ported from the async-read-dev branch but still using blocking reads). I've just reverted the latter to eliminate one possible source of problems. The async write completion is still in place in the trunk. Brian
Problem with apr_time_exp_lt (localtime_r) on AIX
Hi, I am facing a strange problem with apr_time_exp_lt. On AIX, when i call apr_time_exp_lt with 2nd arg as 214748364700LL, it sets the yr as 1 instead on 138. The same works on Linux properly. I investigated the code & found that apr_time_exp_lt internally calls explode_time(). Here, localtime_r is called with arguments (&tt, &tm) where tt=2147483647. localtime_r seems to be having some issue! For checking localtime_r, i wrote a sample program. There also, while passing tt=2147483647, it returned 1 instead of 138. Is this AIX specific? Please help! Thanks in adv! Regards, Lekha http://www.patni.com World-Wide Partnerships. World-Class Solutions. _ This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at [EMAIL PROTECTED] and delete this mail. _
[jira] Updated: (MODPYTHON-137) Add req.server.get_options() for obtain PythonOption values set at global level.
[ http://issues.apache.org/jira/browse/MODPYTHON-137?page=all ] Graham Dumpleton updated MODPYTHON-137: --- Attachment: grahamd_20060228_MP137_1.diff Attached "grahamd_20060228_MP137_1.diff" containing proposed changes. > Add req.server.get_options() for obtain PythonOption values set at global > level. > > > Key: MODPYTHON-137 > URL: http://issues.apache.org/jira/browse/MODPYTHON-137 > Project: mod_python > Type: New Feature > Components: core > Versions: 3.3 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > Attachments: grahamd_20060228_MP137_1.diff > > The req.server.get_config() member seems like it is supposed to allow access > to values of configuration directives set at global context. It seems though > to have a few problems with it though. See MODPYTHON-133 and MODPYTHON-134. > Regardless of that, it seems it may be appropriate to provide an equivalent > for PythonOption directive settings. Specifically req.server.get_options(). > This would return a table object giving all PythonOption value settings > performed at global scope. This would be useful where a value needs to be set > globally in one place and not be overridable in more constrained > configuration containers. > This might for example be used as a way or allowing the mutex directory to be > specified in the Apache configuration as well as as a "configure" command > line option. See MODPYTHON-131. > See commentary along with some patches in: > http://www.mail-archive.com/python-dev@httpd.apache.org/msg01295.html -- 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
AW: httpd-trunk with MSIE (async read broken?) and AJP problems was Re: httpd-trunk sucking CPU on ajax
> Von: Im Auftrag von Justin Erenkrantz > Gesendet: Montag, 27. Februar 2006 22:37 > > >> BTW: Justins idea to exchange the transient buckets with heap buckets was >> also correct >> as it seems that the transient buckets might get overwritten in some >> situations. >> So Justin could you please commit this to the trunk? >> >> Sure, I will do so tonight. -- justin Something that just came up my mind. The problem with the transient bucket should only happen if the bucket is not consumed during the pass_brigade. But if a filter down the chain decides not to consume this bucket for whatever reason it should set it aside and thus transform the transient bucket into a heap bucket. Provided that all filters in the chain work correctly, the patch should not be needed. Sorry for the confusion created :-) Regards Rüdiger
