Re: AW: 2.2 mod_http_proxy and "partial" pages
On 12/14/2005 12:59 AM, Jim Jagielski wrote: > > On Dec 13, 2005, at 1:28 PM, Ruediger Pluem wrote: [..cut..] > > The reason the other patch didn't do this is that, > upon reflection, closing the client connection at > this point does not seem quite right. Closing > it simply because the gateway died just doesn't > feel right, and seems almost overkill. I think > simply setting the error bucket to allow the rest > of the chain to correctly handle it, is the best > we could (and should) do :/ Sorry, but I think I have to disagree. There is nothing that can be handled anymore since the headers had been sent to the client. The only part of the chain that handles error buckets so far is the http header filter which is gone at this point of time. So the client will be most likely waiting for more data on this connection if the content-length was bigger than what was sent so far. So from my point of view closing the connection is the only possibility to signal the client that something got irrevocably wrong. Regards Rüdiger
Re: AW: 2.2 mod_http_proxy and "partial" pages
On Dec 13, 2005, at 1:28 PM, Ruediger Pluem wrote: Index: server/core_filters.c === --- server/core_filters.c»··(Revision 356370) +++ server/core_filters.c»··(Arbeitskopie) @@ -315,8 +315,10 @@ apr_size_t *bytes_written, conn_rec *c); · -static void remove_empty_buckets(apr_bucket_brigade *bb); +static void detect_error_bucket(apr_bucket *bucket, conn_rec *c); · +static void remove_empty_buckets(apr_bucket_brigade *bb, conn_rec *c); + The reason the other patch didn't do this is that, upon reflection, closing the client connection at this point does not seem quite right. Closing it simply because the gateway died just doesn't feel right, and seems almost overkill. I think simply setting the error bucket to allow the rest of the chain to correctly handle it, is the best we could (and should) do :/
Re: AW: 2.2 mod_http_proxy and "partial" pages
Graham Leggett wrote:
>
> > Index: modules/cache/mod_disk_cache.c
> > ===
> > --- modules/cache/mod_disk_cache.c (revision 356419)
> > +++ 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.",
> >
>
> Would mem_cache have to do the same thing? Is there not a way to make
> this generic?
>
> Otherwise +1.
>
Not really, at least as far as I can see (yet! :) ). The reason is
that what we use to trigger a "error happened, don't cache" is
the no_cache flag, and so each would need to check that (which
they should be doing anyway, imo ;) )
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
[PATCH] add --with-mm-opts to Makefile.PL
This isn't quite enough to get -libmodperl to work, but its step1.
Index: Makefile.PL
===
--- Makefile.PL (revision 356406)
+++ Makefile.PL (working copy)
@@ -19,7 +19,7 @@
undef @opts{qw(with-apache2-apxs with-apache1-apxs with-apache2-src
with-perl with-apache2-httpd
with-apr-config with-apu-config apxs
- with-expat)};
+ with-expat with-mm-opts)};
undef @opts{qw(with-apache2)} if (WIN32);
my @flags = qw/enable-maintainer-mode enable-perl-glue
disable-perl-glue/;
"Love is not the one you can picture yourself marrying,
but the one you can't picture the rest of your life without."
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
Re: How to determine if a graceful restart is initiated from within a module
Apologies for the late reply, I was actually looking at this code yesterday, and no there is no convienent way to do it, but why is that you want to ? It'll take some form of IPC to do this, but I'm shortly about to start writing a complete replacement for mod_cgid which we may or may not end up using, so it'd be useful to have feedback on why you need to do this and what additional requirements we can try and fulfill. On Thu, Nov 24, 2005 at 06:17:34PM +0530, Kiran Mendonce wrote: > I wanted to add that I am working om mod_cgid and thats where I want to > check if it is a graceful restart. I did some more investigation and > found that listener_may_exit is not set during a graceful restart for > cgid which is why ap_graceful_stop_signalled() does not return 1. Is > there any way I can find if it is a graceful restart in mod_cgid ? > > Thanks and Regards, > Kiran > > Kiran Mendonce wrote: > > >Hi, > > > >I'd like to know how a module can determine if a graceful restart has > >been issued. I tried using the ap_mpm_query() and the > >ap_graceful_stop_signalled() APIs but I have'nt really been able to > >get what I want. ap_mpm_query() always returns 0 on > >graceful/restart/stop conditions and ap_graceful_stop_signalled() does > >not return 1 on graceful restart. > > > >So I'm confused what to do. Any suggestions ? > > > >Thanks and Regards, > >Kiran > > > > > -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: 2.2 mod_http_proxy and "partial" pages
On 12/13/2005 05:55 PM, Jim Jagielski wrote:
> Eyes please... The coffee is VERY week this morning :)
Yes, I guess it was very weAk ;-). Just teasing. :)
Patch looks good to me. As it is only half of the way I assembled it with the
other
pieces we had and I had sent. The attached patch passed the test with my jsp I
described
earlier (and it really closes the connection to the client :-)).
So some eyes on this one please.
Regards
Rüdiger
P.S: Ignore the garbage signs in the mail version of the patch. Its just a copy
and paste
from my vi.
Index: server/core_filters.c
===
--- server/core_filters.c»··(Revision 356370)
+++ server/core_filters.c»··(Arbeitskopie)
@@ -315,8 +315,10 @@
apr_size_t *bytes_written,
conn_rec *c);
·
-static void remove_empty_buckets(apr_bucket_brigade *bb);
+static void detect_error_bucket(apr_bucket *bucket, conn_rec *c);
·
+static void remove_empty_buckets(apr_bucket_brigade *bb, conn_rec *c);
+
static apr_status_t send_brigade_blocking(apr_socket_t *s,
apr_bucket_brigade *bb,
apr_size_t *bytes_written,
@@ -487,7 +489,7 @@
if (bb == NULL) {
return;
}
-remove_empty_buckets(bb);
+remove_empty_buckets(bb, c);
if (!APR_BRIGADE_EMPTY(bb)) {
c->data_in_output_filters = 1;
if (make_a_copy) {
@@ -526,7 +528,7 @@
struct iovec vec[MAX_IOVEC_TO_WRITE];
apr_size_t nvec = 0;
·
-remove_empty_buckets(bb);
+remove_empty_buckets(bb, c);
·
for (bucket = APR_BRIGADE_FIRST(bb);
bucket != APR_BRIGADE_SENTINEL(bb);
@@ -596,16 +598,25 @@
}
}
·
-remove_empty_buckets(bb);
+remove_empty_buckets(bb, c);
·
return APR_SUCCESS;
}
·
-static void remove_empty_buckets(apr_bucket_brigade *bb)
+static void detect_error_bucket(apr_bucket *bucket, conn_rec *c)
{
+if ((bucket->type == &ap_bucket_type_error) && (((ap_bucket_error
*)(bucket->data))->status == HTTP_BAD_GATEWAY)) {
+/* stream aborted and we have not ended it yet */
+c->keepalive = AP_CONN_CLOSE;
+}
+}
+
+static void remove_empty_buckets(apr_bucket_brigade *bb, conn_rec *c)
+{
apr_bucket *bucket;
while (((bucket = APR_BRIGADE_FIRST(bb)) != APR_BRIGADE_SENTINEL(bb)) &&
(APR_BUCKET_IS_METADATA(bucket) || (bucket->length == 0))) {
+detect_error_bucket(bucket, c);
APR_BUCKET_REMOVE(bucket);
apr_bucket_destroy(bucket);
}
@@ -678,6 +689,7 @@
for (i = offset; i < nvec; ) {
apr_bucket *bucket = APR_BRIGADE_FIRST(bb);
if (APR_BUCKET_IS_METADATA(bucket)) {
+detect_error_bucket(bucket, c);
APR_BUCKET_REMOVE(bucket);
apr_bucket_destroy(bucket);
}
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c»·(Revision 356370)
+++ modules/proxy/mod_proxy_http.c»·(Arbeitskopie)
@@ -1481,12 +1481,18 @@
}
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 = ap_bucket_error_create(HTTP_BAD_GATEWAY, NULL,
+ c->pool, c->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, e);
+e = apr_bucket_eos_create(c->bucket_alloc);
+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 356370)
+++ modules/cache/mod_disk_cache.c»·(Arbeitskopie)
@@ -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 aborte
Re: AW: 2.2 mod_http_proxy and "partial" pages
Graham Leggett wrote: Would mem_cache have to do the same thing? Is there not a way to make this generic? Each cache provider traverses the brigade itself, so at this time, each provider must handle this itself. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: AW: 2.2 mod_http_proxy and "partial" pages
Jim Jagielski wrote:
Eyes please... The coffee is VERY week this morning :)
Despite having overindulged upon the sushi, I shall give it a go :)
Index: modules/cache/mod_disk_cache.c
===
--- modules/cache/mod_disk_cache.c (revision 356419)
+++ 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.",
Would mem_cache have to do the same thing? Is there not a way to make
this generic?
Otherwise +1.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: AW: 2.2 mod_http_proxy and "partial" pages
Eyes please... The coffee is VERY week this morning :)
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 356419)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1481,12 +1481,19 @@
}
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. Pass along a
502 error
+ * bucket
*/
ap_log_cerror(APLOG_MARK, APLOG_ERR, rv, c,
"proxy: error reading
response");
-c->aborted = 1;
+r->no_cache = 1;
+e = ap_bucket_error_create(HTTP_BAD_GATEWAY,
NULL,
+ c->pool, c-
>bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, e);
+e = apr_bucket_eos_create(f->c->bucket_alloc);
+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 356419)
+++ 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: APR: decision which shared mem implementation is used
On Tue, Dec 13, 2005 at 02:08:53PM +0100, Torsten Foertsch wrote:
> [Tue Dec 13 12:09:46 2005] [crit] (17)File exists: unable to create
> scoreboard "/var/opt/apache/logs/apache_scoreboard" (name-based shared memory
> failure)
>
> Deleting /var/opt/apache/logs/apache_scoreboard didn't help. Strace then
> revealed:
>
> unlink("/var/opt/apache/logs/apache_scoreboard") = 0
> open("/var/opt/apache/logs/apache_scoreboard", O_WRONLY|O_CREAT|O_EXCL, 0666)
> = 14
> stat64("/var/opt/apache/logs/apache_scoreboard", {st_mode=S_IFREG|0644,
> st_size=0, ...}) = 0
> shmget(17191678, 225304, IPC_CREAT|IPC_EXCL|0600) = -1 EEXIST (File exists)
You shouldn't really configure a ScoreBoardFile in httpd, it's not
necessary. If you comment that out it should work fine.
The behaviour you see is partly due to apr 0.9.x lacking
apr_shm_remove(), something which was fixed in apr 1.0.x; so this
doesn't affect 2.2.x even with ScoreBoardFile configured.
joe
Re: svn commit: r355823 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h mod_proxy_http.c
Ruediger Pluem wrote: I hope Brian can step in and test it. Currently, we are testing the c->aborted and return DONE patches. It will be next week before I can test further patches as I have to roll out a fixed version of 2.2.0. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
mod_authn_dbd with MySQL
After a few experiments with Win32 mod_authn_dbd with MySQL driver, I found that after some time running it looses connections with the database. And have to restart Apache, nothing in the logs. I build the DBDriver MySQL with the MySQL 4.1.15 libs. Anyone running mod_authn-dbd MySQL without issues under Windows ? Steffen http://www.apachelounge.com
APR: decision which shared mem implementation is used
Hi,
yesterday after a few experiments I found my apache won't start anymore. In the
error_log
it said:
[Tue Dec 13 12:09:46 2005] [crit] (17)File exists: unable to create scoreboard
"/var/opt/apache/logs/apache_scoreboard" (name-based shared memory failure)
Deleting /var/opt/apache/logs/apache_scoreboard didn't help. Strace then
revealed:
unlink("/var/opt/apache/logs/apache_scoreboard") = 0
open("/var/opt/apache/logs/apache_scoreboard", O_WRONLY|O_CREAT|O_EXCL, 0666) =
14
stat64("/var/opt/apache/logs/apache_scoreboard", {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
shmget(17191678, 225304, IPC_CREAT|IPC_EXCL|0600) = -1 EEXIST (File exists)
Well, obviously my apache uses SysV IPC for shared mem and my experiments left
over an
existing shm segment. First, I think, the error_log message is totally
misleading since
nothing is wrong with the file. Better would be something that says which
segment is to
be removed to start apache again.
Second, why is apache using SysV IPC on my linux box at all when mmap() is
available? Is
there a reason or just chance?
Configuring the APR that comes with 2.0.55 says it can use "SysV IPC",
"Classical mmap"
or "POSIX shm_open". On linux the last one is not really an option. The manpage
to shm_open
states:
The operation of shm_open is analogous to that of open(2). name speci‐
fies the shared memory object to be created or opened. For portable
use, name should have an initial slash (/) and contain no embedded
slashes.
Strace reveals that with shm_open apache want's to create
/dev/shm/var/opt/apache/logs/apache_scoreboard
as shared mem. That fails because the directory do not exists. Thus, on linux
the name
parameter to shm_open should not contain embedded slashes.
I think the configure process should check that.
But the mmap shared mem implementation works (by now) on my linux box:
unlink("/var/opt/apache/logs/apache_scoreboard") = -1 ENOENT (No such file or
directory)
open("/var/opt/apache/logs/apache_scoreboard", O_RDWR|O_CREAT|O_EXCL, 0666) = 14
ftruncate(14, 225312) = 0
lseek(14, 225312, SEEK_SET) = 225312
mmap2(NULL, 225312, PROT_READ|PROT_WRITE, MAP_SHARED, 14, 0) = 0x4063d000
close(14) = 0
I think this is better since it avoids hidden shared mem keys or ids.
Why APR configure chooses SysV IPC in the first place? configure.in looks like:
APR_BEGIN_DECISION([namebased memory allocation method])
APR_IFALLYES(header:sys/mman.h func:mmap func:munmap,
[havemmaptmp="1"
APR_DECIDE(USE_SHMEM_MMAP_TMP,
[Classical mmap() on temporary file])])
APR_IFALLYES(header:sys/mman.h func:mmap func:munmap func:shm_open dnl
func:shm_unlink,
[havemmapshm="1"
APR_DECIDE(USE_SHMEM_MMAP_SHM,
[mmap() via POSIX.1 shm_open() on temporary file])])
APR_IFALLYES(header:sys/ipc.h header:sys/shm.h header:sys/file.h dnl
func:shmget func:shmat func:shmdt func:shmctl,
[haveshmget="1"
APR_DECIDE(USE_SHMEM_SHMGET, [SysV IPC shmget()])])
...
APR_END_DECISION
This explains it. SysV IPC wins because it is simply the last.
If what I said makes sense and there is no reason against "Classical mmap" then
maybe
the attached patch can be considered. It changes configure and configure.in.
I have also checked the APR that comes with 2.1.8. The decision process is the
same.
My box is suse linux 9.2 with linux 2.6.8 and glibc 2.3.3.
Torsten
--- httpd-2.0.55/srclib/apr/configure~ 2005-10-10 03:34:19.0 +0200
+++ httpd-2.0.55/srclib/apr/configure 2005-12-13 12:24:10.559527211 +0100
@@ -29272,7 +29272,7 @@
ac_decision=''
ac_rc=yes
-for ac_spec in header:sys/mman.h func:mmap func:munmap; do
+for ac_spec in header:sys/mman.h func:mmap func:munmap func:shm_open func:shm_unlink; do
ac_type=`echo "$ac_spec" | sed -e 's/:.*$//'`
ac_item=`echo "$ac_spec" | sed -e 's/^.*://'`
case $ac_type in
@@ -29297,11 +29297,11 @@
done
if test ".$ac_rc" = .yes; then
:
-havemmaptmp="1"
- ac_decision='USE_SHMEM_MMAP_TMP'
-ac_decision_msg='Classical mmap() on temporary file'
-ac_decision_USE_SHMEM_MMAP_TMP=yes
-ac_decision_USE_SHMEM_MMAP_TMP_msg='Classical mmap() on temporary file'
+havemmapshm="1"
+ ac_decision='USE_SHMEM_MMAP_SHM'
+ac_decision_msg='mmap() via POSIX.1 shm_open() on temporary file'
+ac_decision_USE_SHMEM_MMAP_SHM=yes
+ac_decision_USE_SHMEM_MMAP_SHM_msg='mmap() via POSIX.1 shm_open() on temporary file'
else
:
@@ -29309,7 +29309,7 @@
fi
ac_rc=yes
-for ac_spec in header:sys/mman.h func:mmap func:munmap func:shm_open func:shm_unlink; do
+for ac_spec in header:sys/ipc.h header:sys/shm.h header:sys/file.h func:shmget func:shmat func:shmdt func:shmctl; do
ac_type=`echo "$ac_spec" | sed -e 's/:.*$//'`
ac_item=`echo "$ac_spec" | sed -e 's/^.*:/
