d perform when the back ends are only
lightly or moderately loaded and the front end queue is usually empty.
Greg Ames
y'all have already
decided on the latter. If not, it is trivial to make event behave like
worker, controlled by a config directive if you feel that's necessary. I
believe the code is in ap_process_async_connection. I *really* regret not
doing that in the first event patch I posted to this list. Que sera, sera.
Enough ranting.
Greg Ames
see PR 49504 https://issues.apache.org/bugzilla/show_bug.cgi?id=49504 for
an excellent analysis with supporting traces. There have been various
other PRs that haven't led to resolution, perhaps because it is easy to
circumvent via AcceptMutex sysvsem and is highly timing dependent.
The problem
On Wed, Jan 25, 2012 at 8:00 AM, Jeff Trawick traw...@gmail.com wrote:
I'll start with the patch for CVE-2011-4317.
The 2.2.x patch for CVE-2011-3607 (r1227280) applies and builds fine
on 2.0.x. Vote in STATUS?
Greg
On Tue, Dec 20, 2011 at 4:26 AM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
We should come to a conclusion on this.
How about this for 2.2.x ?
--- server/util.c (revision 1179624)
+++ server/util.c (working copy)
@@ -82,6 +82,8 @@
#define IS_SLASH(s) (s == '/')
#endif
+/*
On Thu, Dec 1, 2011 at 2:52 PM, Yuri Arabadji y...@fused.com wrote:
We've got mpm worker with the following config:
http://stage.fused.net/huy#worker.c
MaxSpareThreads 250
MinSpareThreads 25
ThreadsPerChild 25
ServerLimit 30
MaxClients 750
It's pretty obvious the total number of
On Tue, Nov 22, 2011 at 9:15 AM, Jeff Trawick traw...@gmail.com wrote:
So I have to ask: is the intent to really release 2.4.0 anytime soon,
or are is it a simple sandbox for people to play around in?
It is safe to predict how that question would be answered ;)
Alternately, Let's plan
On Tue, Nov 15, 2011 at 10:51 AM, pque...@apache.org wrote:
Log:
Create a new lock free circular queue, and use it in the EventMPM to
remove the timeout mutex that was wrapping both timeout queue operations
and pollset operations.
@@ -1632,6 +1672,20 @@ static void * APR_THREAD_FUNC
On Fri, Nov 18, 2011 at 3:48 PM, Jeff Trawick traw...@gmail.com wrote:
Try this:
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1203816)
+++ server/mpm/event/event.c(working copy)
@@ -1483,9
On Fri, Nov 18, 2011 at 4:38 PM, Jeff Trawick traw...@gmail.com wrote:
but my fears about the performance of the design seem to be confirmed.
my
fastest run so far with trunk + this patch,
Requests per second:7749.66 [#/sec] (mean)
backing up to the prior state (with the mutex),
On Fri, Nov 11, 2011 at 11:07 PM, Paul Querna p...@querna.org wrote:
4) Have the single Event thread de-queue operations from all the worker
threads.
Since the operations include Add and Remove, are you saying we would have
to have to wait for a context switch to the listener thread before
On Mon, Nov 14, 2011 at 11:12 AM, Paul Querna p...@querna.org wrote:
The problem became that in trunk, we had to told the lock for the
timeout queues while we were doing the pollset operation. The
pollset already had its own internal mutex too, for its own rings. So
we were double locking
On Thu, Nov 10, 2011 at 4:12 PM, Stefan Fritsch s...@sfritsch.de wrote:
Hi,
I intend to set MaxMemFree by default.
+1.
What about a way to view allocator memory use? per child totals in
mod_status would be most excellent.
Greg
On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski j...@jagunet.com wrote:
On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
Maybe I misunderstood, but I thought Rüdiger's original point was on
track: EAGAIN here is a bug to fix somewhere since EAGAIN from
blocking read is should-not-occur,
On Thu, Nov 3, 2011 at 4:09 PM, Jeff Trawick traw...@gmail.com wrote:
On Thu, Nov 3, 2011 at 3:38 PM, Greg Ames ames.g...@gmail.com wrote:
On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski j...@jagunet.com wrote:
On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
I worked on a bug about
On Fri, Oct 14, 2011 at 2:34 PM, Stefan Fritsch s...@sfritsch.de wrote:
In pre-2.4, it seems we could be more tolerant than 10 subs or 8K
if we're going to be returning a NULL that's never been returned
in practice.
Introducing an arbitrary length limit seems pretty invasive for 2.2.x.
On Fri, Oct 14, 2011 at 4:44 AM, Nick Kew n...@webthing.com wrote:
If we include it in 2.4 then we're making libxml2 a dependency.
That's of concern primarily to packagers,
I doubt that I could find libxml2 for z/OS. I vote for keeping it a
separate module.
but it's a decision
we should
On Tue, Aug 30, 2011 at 12:48 PM, William A. Rowe Jr.
wr...@rowe-clan.netwrote:
On 8/30/2011 10:18 AM, Jim Jagielski wrote:
If we get enough votes by, say, 1:30pm Eastern time (2hrs), I'll retag
and reroll… Otherwise, I'll go ahead w/ releasing 2.2.20.
PS: Power and net are bouncing like
On Tue, Aug 30, 2011 at 1:54 PM, Jim Jagielski j...@jagunet.com wrote:
Could I get at least 1 more binding vote…??
yep. +1
Greg
On Sat, Aug 27, 2011 at 4:44 PM, Eric Covener cove...@gmail.com wrote:
[ x ] just the cheap brigade copy + sum_len clen failsafe
and I like the idea of having a runtime switch to turn off merging in
trunk. it could take care of client breakage as well as making it easy to
keep 2.2 in sync.
On Sun, Aug 28, 2011 at 4:22 PM, Stefan Fritsch s...@sfritsch.de wrote:
looks good overall.
+while (start64 - off_first (apr_uint64_t)copy-length) {
+apr_bucket *tmp;
+int i = 0;
+if (i++ = 9)
+
On Mon, Aug 29, 2011 at 12:40 PM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
I am fine with this on 2.2.x. +1.
+1 here too
On Mon, Aug 29, 2011 at 4:38 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote:
On 8/29/2011 10:40 AM, j...@apache.org wrote:
Author: jim
Date: Mon Aug 29 15:40:19 2011
New Revision: 1162874
Changes with Apache 2.2.20
+ *) SECURITY: CVE-2011-3192 (cve.mitre.org)
+ core: Fix
On Thu, Aug 25, 2011 at 7:02 PM, s...@apache.org wrote:
Log:
Put parsed ranges into an array and perform merges on that array.
+if (i 0) {
+if (!(ranges[i].start ranges[i-1].end + 1
+ ranges[i].endranges[i-1].start - 1))
+{
+
On Thu, Aug 25, 2011 at 7:02 PM, s...@apache.org wrote:
+if (!(ranges[i].start ranges[i-1].end + 1
+ ranges[i].endranges[i-1].start - 1))
and the if condition looks similar. the first test is fine, but why is
ranges[i].end ranges[i-1].start a good
-2000
or
2000-3000,1500-2500
But I think this check is currently wrong as you point out. Currently not
sure how to fix it.
Regards
Rüdiger
--
*From:* Greg Ames [mailto:ames.g...@gmail.com]
*Sent:* Freitag, 26. August 2011 16:58
*To:* dev@httpd.apache.org
On Fri, Aug 26, 2011 at 10:27 AM, Jim Jagielski j...@apache.org wrote:
I guess we can do both: Count the ',' and give the number to
apr_array_make
Doesn't that mean that someone can craft a nasty Range (e.g: 0-0,1-1,2-2,
3-3,….- and cause us to preallocate a bunch
of
On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski j...@jagunet.com wrote:
Now that the memory utilz is being fixed, we need to determine
what sort of usage we want to allow… I'm guessing that people
are ok with http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
as the guiding spec?
I'm no
On Thu, Aug 25, 2011 at 5:43 PM, s...@apache.org wrote:
avoid inserting the same bucket into bbout twice, causing an endless loop
--- httpd/httpd/trunk/modules/http/byterange_filter.c (original)
+++ httpd/httpd/trunk/modules/http/byterange_filter.c Thu Aug 25 21:43:32
2011
@@ -195,8 +195,8
On Wed, Aug 24, 2011 at 9:01 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
Hmm - when I remove mod_deflate (i.e. explicitly as it is the
default in all our installs) and test on a / entry which is a
static file which is large (100k)* - then I cannot get apache
on its
On Wed, Aug 24, 2011 at 10:56 AM, Dirk-Willem van Gulik
di...@webweaving.org wrote:
+1 with Eric's edits. specifically,
1) Use mod_rewrite to limit the number of ranges:
Option 1 doesn't use mod_rewrite.
Option 1:
# drop Range header when more than 5 ranges.
#
On Wed, Aug 24, 2011 at 10:33 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
**
I think mod_deflate is just the tool to convert an O(N^2) data size problem
into an O(N^2) CPU usage problem, where N is some function of
LimitRequestLine. If the file size is smaller than the
On Wed, Aug 24, 2011 at 12:42 PM, Jim Jagielski j...@jagunet.com wrote:
On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote:
0-, 40-50 becomes 0-
0-499, 400-599 becomes 0-599
1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250
This goes against Roy's recommendation to
On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com wrote:
If we only merge adjacent ascending ranges, then it seems like an
attacker could just craft a header where the ranges jump around and dodge
our fix.
I think no matter what, we should still have some sort of
upper
On Wed, Aug 24, 2011 at 5:06 PM, Jim Jagielski j...@jagunet.com wrote:
I'm cool w/ that… treat non-ascending ranges as potential hinky
and count those and only allow a certain number of them…
Still not sure if we should count overlaps as bad or not…
that RFC example troubles me:
14.35.1
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch s...@sfritsch.de wrote:
I have another idea: Instead of using apr_brigade_partition write a
new function ap_brigade_copy_part that leaves the original brigade
untouched. It would copy the necessary buckets to a new brigade and
then split the
On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote:
I suggest we should be parsing and reassembling the list before we
start the bucket logic.
I propose we satisfy range requests in the only sensible manner, returning
the ranges in sequence,
yeah, overlapping
I don't remember any discussions on the subject or reasons why the timing is
as late as it is. I assume signal handlers are cloned by the fork(). ++1 to
eliminating silent failures.
Greg
On Sun, Jul 24, 2011 at 2:25 PM, Stefan Fritsch s...@sfritsch.de wrote:
Hi,
the Unix MPMs detach from
On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch s...@sfritsch.de wrote:
Speaking about config options, I think that MaxClients should be
renamed to MaxWorkers, because it limits the number of worker threads,
not the number of clients. As with the MaxRequestsPerChild -
MaxConnectionsPerChild
hey I like the concept a lot! a quick peek at
http://apache.org/server-status shows 15 Cs for threads tied up in lingering
close, something like 50 Keepalive threads, and only 13 threads actually
reading or writing.
On Mon, Apr 25, 2011 at 8:53 PM, Jeff Trawick traw...@gmail.com wrote:
has
On Tue, Oct 12, 2010 at 5:22 PM, Jeff Trawick traw...@gmail.com wrote:
Someone mentioned using 2.2 event in production on the list,today or
yesterday, so I peeked at 2.2 and this bug appears to affect it. Any
interest out there in seeing what it takes to backport?
yes, I'd like to see it
In 2.2, it is expected behavior. The RFC allows the server to close
keepalive connections when it wants.
The last time I checked, trunk had a related bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43359 . Connections
waiting for network writes can also be handled as poll events. But
I re-read this thread and see that we have a request in progress, so this
isn't RFC approved behavior. Sorry for the noise.
Greg
On Sun, Apr 25, 2010 at 2:07 PM, Rainer Jung rainer.j...@kippdata.dewrote:
On 23.03.2010 15:30, Jeff Trawick wrote:
Is that expected behaviour? It doesn't seem
On Thu, Apr 29, 2010 at 12:06 PM, Greg Ames ames.g...@gmail.com wrote:
The last time I checked, trunk had a related bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43359 .
. I will look at the patch again and forget mod_status bells and whistles
for now.
OK, I reviewed this patch
On Tue, Sep 15, 2009 at 8:07 AM, Jeff Trawick traw...@gmail.com wrote:
On Mon, Sep 14, 2009 at 4:27 PM, Greg Ames ames.g...@gmail.com wrote:
I'm trying to debug a problem where apparently the accept mutex went bad
on a z/OS system running the worker MPM. I'm guessing that some memory
I'm trying to debug a problem where apparently the accept mutex went bad on
a z/OS system running the worker MPM. I'm guessing that some memory that we
use for the semaphore got clobbered but don't have proof yet. The error log
looks like:
[Mon Sep 07 08:01:59 2009] [emerg] (121)EDC5121I
On Tue, Jul 14, 2009 at 11:47 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
All very true. But how about the following patch. It should do no
harm and should solve the issue in at least some cases (I think
in most cases):
Index: modules/filters/mod_deflate.c
+if
+1
Greg
On Fri, Oct 10, 2008 at 10:36 AM, Jim Jagielski [EMAIL PROTECTED] wrote:
Based on the positive feedback on the test tarballs, I'd
like to start a vote on releasing 2.2.10. I'm looking to
release on Tuesday, since I'll be traveling Monday, so I'll
close the vote on Tues AM.
On Thu, Oct 9, 2008 at 5:29 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
Does anybody see problems with this or are we still too worried about
the correct handling of signed vs. unsigned variables by apr_atomic_
to use this in a non experimental MPM?
signed vs unsigned doesn't bother me.
On Fri, Oct 10, 2008 at 10:31 AM, Greg Ames [EMAIL PROTECTED] wrote:
I will take a look at the APR atomics and see if the operations that
Event's fdqueue is using are less supported than the atomics used in
worker.
No difference in support on ia32 + gcc; both worker and event use two mutex
On Tue, Oct 7, 2008 at 7:03 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
One comment in the event version of ap_queue_info_wait_for_idler confuses
me:
* A negative value in queue_info-idlers tells how many
* threads are waiting on an idle worker.
IMHO this would require
On Tue, Oct 7, 2008 at 7:03 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
I am currently looking at PR45605 (
https://issues.apache.org/bugzilla/show_bug.cgi?id=45605)
and the analysis and the resulting patch in Comment 4 look good to me
On Tue, Oct 7, 2008 at 2:37 PM, Jim Jagielski [EMAIL PROTECTED] wrote:
... at the usual location:
http://httpd.apache.org/dev/dist/
The availability of these test tarballs does not constitute
an official release, however please download and test
as a VOTE will be called for in the
On Tue, Oct 7, 2008 at 5:11 AM, Ruediger Pluem [EMAIL PROTECTED] wrote:
The
problem is that they all stay ESTABLISHED for KeepAliveTimeout seconds.
I
was expecting to see 2 of them drop after 30 seconds. Any suggestions?
You need one more request after 30 seconds to trigger this
On Mon, Oct 6, 2008 at 3:13 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 10/06/2008 04:42 PM, Jim Jagielski wrote:
Subj says it all...
Thanks for doing RM Jim. So c'mon guys. There must be someone
out there that reviews the remaining patch that misses only
*one* vote.
what do I need
On Mon, Oct 6, 2008 at 4:34 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
Thanks for reviewing. First of all I guess you should increase the
KeepAliveTimeout
to a large value like 5 minutes to make observations easier. Furthermore I
would increase
the ttl parameter of your BalancerMember to
On Sat, Sep 6, 2008 at 4:38 AM, Ruediger Pluem [EMAIL PROTECTED] wrote:
+bb = apr_brigade_create(r-pool, c-bucket_alloc);
This is bad. Please store the brigade in the filter context and reuse it,
by cleaning it. See also
On Sun, Sep 7, 2008 at 8:57 AM, Arnab Ganguly [EMAIL PROTECTED] wrote:
Hi All,
How do I enable lingering_close in Apache.Is it enabled by default in
Apache 2.2.8 ?
yes.
Is there anyway to check it.
Trace the system calls. On Linux, you can run strace against one of the
worker
word syncronize once more
Greg Ames wrote:
please see rev. 558039. requests_this_child does not need to be 100%
accurate. the cure below is worse than the disease.
Greg
-requests_this_child--; /* FIXME: should be synchronized - aaron */
+apr_atomic_dec32
please see rev. 558039. requests_this_child does not need to be 100% accurate.
the cure below is worse than the disease.
Greg
- Original Message
From: Dmytro Fedonin [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Thursday, June 14, 2007 11:49:42 AM
Subject: one word syncronize once
no objections in principle to your suggested changes. but in practice, I don't
see where an error bucket gets flagged as metadata. seems like they should be.
Greg
- Original Message
From: Ruediger Pluem [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Saturday, July 7, 2007 4:13:08 PM
PM
Subject: Re: svn commit: r554011 -
/httpd/httpd/trunk/modules/filters/mod_deflate.c
On 07/10/2007 09:27 PM, Greg Ames wrote:
no objections in principle to your suggested changes. but in practice, I
don't see where an error bucket gets flagged as metadata. seems like they
should be.
How
check_pipeline: use AP_MODE_SPECULATIVE to check for data in the input
filters
to accomodate mod_ssl's input filter. AP_MODE_EATCRLF is essentially a
no-op
in that filter.
EATCRLF was used here for a specific reason though - the fact that many
browsers (says ap_core_input_filter)
--- Ruediger Pluem [EMAIL PROTECTED] wrote:
check_pipeline: use AP_MODE_SPECULATIVE to check for data in the input
filters
to accomodate mod_ssl's input filter. AP_MODE_EATCRLF is essentially a
no-op
in that filter.
EATCRLF was used here for a specific reason though - the fact that
--- Henri Gomez [EMAIL PROTECTED] wrote:
Hi to all,
I'm trying to adapt mod_jk to i5/OS v5r4 and see the following in
mod_jk.log (debug mode)
[Tue Apr 17 16:23:44 2007] [6589:0038] [debug] jk_uri_worker_map.c
(423): rule map size is 0
[Tue Apr 17 16:23:44 2007] [6589:0038] [error]
--- steve [EMAIL PROTECTED] wrote:
I use it too, and have meddled with it enough at a source level to feel
comfortable running it. It has obvious, documented, problems (don't use
it with mod_ssl),
I didn't make it clear earlier -- I do use the event mpm.
Successfully. What *is* the
--- David Jones [EMAIL PROTECTED] wrote:
zOS needs to compile with extra CFLAGS in order to link correctly.
After revisions 153273/153266 to ./Makefile.in all compile and link flags
are lost as
buildmark.c is made without them:
concept sounds fine but...
--- Makefile.in.orig Wed Jan 17
Markus Litz wrote:
Hello,
how can i get the filename only of the requested uri? For example if
http://www.example.com/test.html; is requestet, i only want test.html.
request_rec::filename only gives the full filename on disk.
basename(r-filename)
Greg
Jeff Trawick wrote:
I have been working with a user on one of these fork bomb scenarios
and assumed it was the child_init hook. But after giving them a test
fix that relies on a child setting scoreboard fields in child_main
before child-init hooks run, and also adds some debugging traces
Jeff Trawick wrote:
After a fix to prevent the fork bomb during slow child startup is
applied, something REALLY strange and completely unanticipated has to
happen to get the scoreboard is full, not at MaxClients message.
True?
true. no clue what else might trigger it at this point.
Jeff Trawick wrote:
There are problems accounting for child processes which are trying to
initialize that result in the parent thinking it needs to create more
children. The less harmful flavor is when it thinks (incorrectly) it
is already at MaxClients and issues the reached MaxClients
Saju Pillai wrote:
I can understand why serializing apr_pollset_poll() accept() for the
listener threads doesn't make sense in the event-mpm. A quick look
through the code leaves me confused about the following ...
It looks like all the listener threads epoll() simultaenously on the
Paul Querna wrote:
This is traditionally called the 'Thundering Herd' Problem.
When you have N worker processes, and all N of them are awoken for an
accept()'able new client. Unlike the prefork MPM, N is usually a smaller
number in Event, because you don't need that many EventThreads Per
Saju Pillai wrote:
For a brand new client connection, why should there be 2 exchanges
between the listener thread and the worker thread before the request is
actually read ?
The client socket is accepted() and passed to a worker thread which runs
the create_connection hooks and marks the
Paul Querna wrote:
The event mpm expects the apr_pollset backends to be based on epoll()
/ kqueue() or Solaris 10 event ports. What are the reasons because of
which poll() is not considered to be suitable for the event mpm ?
Is this because of the large number of fd's to be polled and
Jeff Trawick wrote:
It isn't clear to me what an input filter should do about
Content-Length when it modifies the length of the body (assuming that
this isn't chunked encoding).
mod_cgi uses brigades to read the body but needs to look at
Content-Length before spawning the CGI script, so
Scott A. Guyer wrote:
I would like to know more about the process
flow of the event MPM. The docs indicate it was largely
about moving listening logic for keep-alives out of the
worker threads and into the listener thread.
the basic concept of the event MPM is to reduce the amount of
Roy T. Fielding wrote:
On Oct 19, 2005, at 8:35 AM, Greg Ames wrote:
let's say it is a HEAD request for a local static file. the
default_handler calls ap_set_content_length which creates a C-L
header. but then the body could be run through some length changing
filter, such as mod_deflate
Roy T. Fielding wrote:
On Oct 18, 2005, at 3:58 PM, Greg Ames wrote:
Index: server/protocol.c
===
--- server/protocol.c (revision 326257)
+++ server/protocol.c (working copy)
@@ -1302,7 +1302,13 @@
* We can only set a C
Brian Pane wrote:
I think one contributor to the event results is an issue that Paul Querna
pointed out on #httpd-dev the other day: apr_pollset_remove runs in O(n)
time with n descriptors in the pollset.
thanks, I see it. yeah we are going to have to do something about that.
Greg
...a.k.a. Windows Update doesn't work through an httpd-2.* proxy. it looks like a
regression from 1.3.
the interesting stuff happens in ap_content_length_filter. it calculates the new content
length by traversing the output brigade. but in this case, the brigade consists of only
an EOS
Brian Pane wrote:
On Oct 10, 2005, at 12:01 AM, Paul Querna wrote:
If the content has already been generated, why add the overhead of
the context switch/sending to another thread? Can't the same event
thread do a non-blocking write?
Once it finishes writing, then yes, we do require a
Greg Ames wrote:
this is interesting to me because Brian Atkins recently reported that
s/Atkins/Akins/ sorry, Brian
Greg
Brian Akins wrote:
Basically, I was referring to the overall hits a box could serve per
second.
with 512 concurrent connections and about an 8k file, 2.1 with worker
served about 22k request/second. event served about 14k.
do you recall if CPU cycles were maxed out in both cases?
thanks,
Brian Pane wrote:
With the batch of commits I did this weekend, the Event MPM in
the async-dev Subversion branch now does write completion
in a nonblocking manner.
very cool!
There are several more things that need to be fixed in order
to make the asynchronous write completion useful in a
[EMAIL PROTECTED] wrote:
use Greg's cleaner fix for CAN-2005-2970
Modified:
@@ -823,6 +818,7 @@
free(ti);
ap_scoreboard_image-servers[process_slot][thread_slot].pid = ap_my_pid;
+ap_scoreboard_image-servers[process_slot][thread_slot].tid =
apr_os_thread_current();
Peter Djalaliev wrote:
Where does the Apache web server first detect that a request is over HTTPS?
I can't find the specific place in the source code where this is done
(assuming a specific place exists).
my (non-expert) guess: shortly after the request is mapped to an IP
based virtual host
Paul Querna wrote:
Brian Pane wrote:
On the subject of asynchronous write completion, I've drawn a
connection state model that
combines the current state transitions of the event MPM with new states
for write completion
and the handler phase.
Very cool diagram.
amen.
I see a tiny
Brian Pane wrote:
Rather than automatically setting TCP_NODELAY in core_pre_connection(),
perhaps we should set it conditionally in core_output_filter(), where
we have
enough information to tell whether it's needed.
I'm +1 on the concept of being more lazy about setting the sockopts. the
Greg Ames wrote:
Brian Pane wrote:
I'm eager to hear some feedback on this idea:
* Will it work? Or am I overlooking some design flaw?
it should work as long as everything important that happens after the
check_pipeline_flush call still gets done somehow. a quick glance at
the code
Brian Pane wrote:
Looking at the pattern of calls to ap_core_output_filter() in the event
MPM, it occurred to me that it may be straightforward to hand off the
writing of the request to an async completion thread in a lot of useful
real-world cases.
In function check_pipeline_flush() in
Paul Querna wrote:
once I got past that, it just worked. my tests were fairly simple. I
had pipelining enabled in mozilla and also created a script that did
HTTP/1.1 pipelining. if anyone can think of other scenarios I should
test with mod_ssl please let me know.
Yes... I believe it will
my biggest hurdle in getting the event MPM to work with mod_ssl was learning how
to create a self signed server cert with openssl.
http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#ownca is very good but refers
to a sign.sh script that I couldn't find in httpd-2.x . I assume sign.sh was
part
Paul Querna wrote:
Yes... I believe it will 'mostly' work, but the issue becomes tricky
once you consider the SSL protocol. The problem is we might have an
entire pipe-lined request buffered inside the SSL Packets, and
therefore, never trigger the socket to come out of the poll(). For
simple
Joe Orton wrote:
You can create a self-signed cert for mod_ssl testing with just one
command: openssl req -x509 -nodes -new -out foo.cert -keyout foo.key
the docs are a bit too helpful there really.
thanks Joe! this looks like a time saver.
Greg
I noticed that multiple packets are being sent to the network when one would do
on a couple of Linux 2.6.x boxes. one is SuSE SLES 9, the other is RHEL 4. the
first packet is all the HTTP headers, the second is the body/file. strace
http://people.apache.org/~gregames/rhel4.cork.strace
Greg Ames wrote:
Brian Akins wrote:
We've been doing some testing with the current 2.1 implementation, and
it works, it just currently doesn't offer much advantage over worker
for us. If num keepalives == maxclients, you can't accept anymore
connections.
that's a surprise
Brian Akins wrote:
Bill Stoddard wrote:
If the event MPM is working properly, then a worker thread should not
be blocking waiting for the next ka
request. You still have the overhead of the tcp connection and some
storage used by httpd to manage connection
events but both of those are small
William A. Rowe, Jr. wrote:
Will, can you help me understand your concern? this doesn't change the headers of the POST request. it only affects which new headers we generate for the new SSI GET subrequest.
Well I totally understand the issue - I'm blowing up in some PHP
code due to an earlier
http://people.apache.org/~gregames/thread_create_recovery.patch
design:
* exit with APEXIT_CHILDSICK for thread create failures (same as other patches)
* add logic to the parent to decide how bad these errors really are. if we
can't initialize a single worker process, just give up. otherwise
1 - 100 of 536 matches
Mail list logo
