On Sun, Jun 6, 2010 at 5:03 AM, Graham Leggett minf...@sharp.fm wrote:
[...]
We've also been playing with Varnish, one of the cooler things it does is
have the ability to suck up an entire response into a RAM buffer and
releasing the backend before playing out the response to the browser. I've
On Fri, Jun 4, 2010 at 2:18 AM, Mark Nottingham m...@mnot.net wrote:
[...]
It's not a bug in the implementations, it's a grey area in 2616 that HTTPbis
has since worked to resolve;
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147
By my reading of the attachments in that ticket, servers
On Fri, Jun 4, 2010 at 6:10 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
[...]
Isn't that what Transfer-Encoding is designed for?
Yes, and in fact if we were talking about a brand new protocol, I'd
probably argue in favor of putting the compression specifier in the
On Wed, Jun 2, 2010 at 3:29 AM, Jeffrey E Burgoyne burgo...@keenuh.com wrote:
4 - 1 compression ratio is fine unless you are serving lots of rich
content, which generally will see no performance gain if not reduced
performance.
The rich content doesn't need to go through the deflate filter,
On Wed, Jun 2, 2010 at 3:37 AM, Nick Kew n...@webthing.com wrote:
On 2 Jun 2010, at 10:49, Joe Orton wrote:
Maybe we should have a strict API here rather than a loose one:
filters MUST NOT pass an empty brigade down the filter chain.
That's not really an API, it's a rule, and pretty-much
In a filter module I'm writing, it's possible for the first pass
through the output filter to end up calling:
ap_pass_brigade(f-next, an_empty_brigade)
If mod_deflate's output filter appears later in the output filter
chain, bad things happen:
1. On the first trip through the output filter
On Tue, Jun 1, 2010 at 10:28 AM, Matthew Steele mdste...@google.com wrote:
I went ahead and created a bug entry/patch to make the (trivial)
change to mod_deflate to make it conform to the Guide to writing
output filters:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49369
Brian, does
On Tue, Jun 1, 2010 at 9:04 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote:
[...]
Plus deflate may provide no benefit, and degrade performance, if the CPU
utilization is a greater concern than bandwidth utilization.
The CPU utilization is an interesting topic for me because I've been
working
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
Justin Erenkrantz wrote:
On Sun, Feb 26, 2006 at 11:55:31PM -0800, Sander Temme wrote:
Issues.apache.org, which is running trunk or something very close to
it to debug the JIRA issues, has some child processes sucking extreme
quantities of CPU. For instance:
Also, we're getting
On Jan 30, 2006, at 4:05 AM, Joe Orton wrote:
On Mon, Jan 23, 2006 at 08:04:02AM -, Brian Pane wrote:
Author: brianp
Date: Mon Jan 23 00:04:01 2006
New Revision: 371484
URL: http://svn.apache.org/viewcvs?rev=371484view=rev
Log:
Return APR_EAGAIN instead of SSL_ERROR_WANT_READ from
.
Thanks,
Brian
On Jan 7, 2006, at 11:57 PM, Brian Pane wrote:
On Jan 3, 2006, at 8:07 AM, Justin Erenkrantz wrote:
AFAICT, ap_read_async_request() on the branch can't handle a partial
line correctly.
Noting of course that ap_core_input_filter is 'cute' and masks EAGAIN.
So, you'll never see
On Jan 3, 2006, at 8:07 AM, Justin Erenkrantz wrote:
AFAICT, ap_read_async_request() on the branch can't handle a partial
line correctly.
Noting of course that ap_core_input_filter is 'cute' and masks EAGAIN.
So, you'll never see EAGAIN from this code path! As I said earlier,
the EAGAIN
On Jan 2, 2006, at 3:41 PM, Justin Erenkrantz wrote:
+static apr_status_t process_request_line(request_rec *r, char *line,
+ int skip_first)
+{
+if (!skip_first (r-the_request == NULL)) {
+/* This is the first line of the request */
+
On Jan 2, 2006, at 11:52 AM, Roy T. Fielding wrote:
It would be feasible to build up the pending request in a structure
other than the request_rec, so that ap_read_async_request() can
operate on, say, an ap_partial_request_t instead of a request_rec.
My preference so far, though, has been to
On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
On Jan 2, 2006, at 1:37 PM, Brian Pane wrote:
Significantly faster than prefork has never been a litmus test for
assessing new features, and I'm -1 for adding it now. A reasonable
technical metric for validating the async changes would
On Dec 31, 2005, at 3:01 AM, Paul Querna wrote:
I haven't been able to reproduce this since reporting it, and I am
still running the Event MPM, but I did recently upgrade from
FreeBSD 5.4 - 6.0... If its a rare race condition, that might be
enough to hide it.
The bucket allocator cleanup
On Dec 31, 2005, at 6:50 PM, Roy T. Fielding wrote:
The nonblocking yield should happen inside ap_rgetline (or its
replacement), not in the calling routine. The thread has nothing
to do until that call is finished or it times out.
On the contrary, the thread has some very important work to
I haven't been able to find the bug yet. As a next step, I'll try using
valgrind on a build with pool debugging enabled.
Brian
On Dec 4, 2005, at 11:14 PM, Paul Querna wrote:
I finally got around to upgrading to trunk w/ the Event MPM on one
of my
machines. Within a couple hours of
On Dec 30, 2005, at 6:48 PM, Roy T. Fielding wrote:
On Dec 30, 2005, at 5:51 PM, Brian Pane wrote:
I haven't been able to find the bug yet. As a next step, I'll try
using
valgrind on a build with pool debugging enabled.
On entry to allocator_free, if
(node == node-next node-index
On Dec 4, 2005, at 11:14 PM, Paul Querna wrote:
I finally got around to upgrading to trunk w/ the Event MPM on one
of my
machines. Within a couple hours of starting it, I had a process
spinning, and consuming 100% CPU.
Backtrace from the spinning thread:
(gdb) thread 6
[Switching to thread
William A. Rowe, Jr. wrote:
Paul Querna wrote:
Best guess is that we corrupted a bucket brigade by double freeing it,
or something of that kind. This is definitely a new behavior since the
async-write code was merged into trunk.
It is odd that we could of double-free'ed something on the
On Dec 5, 2005, at 10:30 AM, Brian Pane wrote:
William A. Rowe, Jr. wrote:
Paul Querna wrote:
Best guess is that we corrupted a bucket brigade by double
freeing it,
or something of that kind. This is definitely a new behavior
since the
async-write code was merged into trunk
[EMAIL PROTECTED] wrote:
Author: brianp
Date: Sun Nov 27 18:56:47 2005
New Revision: 349348
URL: http://svn.apache.org/viewcvs?rev=349348view=rev
Log:
More refactoring of ap_read_request() in preparation for
nonblocking read support.
WARNING: The code for handlng requests that exceed the
On Nov 26, 2005, at 2:08 AM, Joe Orton wrote:
On Fri, Nov 25, 2005 at 08:18:51PM -0800, Brian Pane wrote:
I think the usual reason that the apr_palloc+memset pattern is
used instead of apr_pcalloc in httpd and APR code is to allow
the compiler generate inline code to fill the structure
On Nov 21, 2005, at 1:34 PM, Christophe Jaillet wrote:
Around line 61 in function ap_queue_info_create, in 'server/mpm/
fdqueue.c'
the following sequence can cleaned-up :
===
qi = apr_palloc(pool, sizeof(*qi));
memset(qi, 0, sizeof(*qi));
I've created a new branch off of the httpd trunk:
https://svn.apache.org/repos/asf/httpd/httpd/branches/async-read-dev/
The old async-dev branch is rather out of date at this point, and
all its nonblocking write code has since been committed to the
trunk. Rather than doing a monstrous merge to
Now that we have nonblocking write completion support in the Event MPM,
I've begun thinking about how to implement nonblocking, event-driven
reads
of incoming requests. Here's a diagram of the connection state
diagram with
some minor changes to support nonblocking reads:
On Nov 20, 2005, at 1:34 PM, Phillip Susi wrote:
Actually you have to use a peg revision, not -r. If you try -r to
look at the deleted branch, svn tries to find the named directory
in the HEAD revision, then look up it's state as it existed in rev
x. This will fail since it does not
On Nov 12, 2005, at 2:21 PM, Vadim Chekan wrote:
On 11/12/05, Jeff Trawick [EMAIL PROTECTED] wrote:
On 11/12/05, Vadim Chekan [EMAIL PROTECTED] wrote:
Hi all,
I've tryed to compile httpd/trunk and got an error:
core_filters.obj : error LNK2019: unresolved external symbol
On Nov 11, 2005, at 6:21 PM, Jeff Trawick wrote:
On 11/11/05, Brad Nicholes [EMAIL PROTECTED] wrote:
On 11/11/2005 at 1:40:32 pm, in message
[EMAIL PROTECTED], Jeff
Trawick
[EMAIL PROTECTED] wrote:
On 11/11/05, Brad Nicholes [EMAIL PROTECTED] wrote:
Reposting to the APR list with a new
On Oct 30, 2005, at 4:17 AM, Joe Orton wrote:
On Sun, Oct 30, 2005 at 09:56:45AM +, Joe Orton wrote:
On Sat, Oct 29, 2005 at 02:23:51PM -0700, Brian Pane wrote:
With fix 329484 committed, I'm now getting a clean test run of the
perl_framework tests with --enable-pool-debug=all
Thanks
On Oct 30, 2005, at 2:09 PM, Peter Djalaliev wrote:
Hello,
I understand that a module registers its own functions for
different hooks
in order to introduce its own functionality at different points of
a request
handling. I also understand that the module can specify if it wants
its
On Oct 30, 2005, at 2:46 PM, Nick Kew wrote:
On Sunday 30 October 2005 22:40, Brian Pane wrote:
Strictly speaking, there's no guarantee that a request will be
processed by one and only one thread. It's possible for a
threaded MPM to hand off a request from one thread to another.
For example
On Oct 28, 2005, at 1:10 AM, Joe Orton wrote:
There are still crashes in free() for an --enable-pool-debug build
(prefork); backtraces like the below seem to show that r-pool is
getting destroyed way too early by the looks of it.
I just figured out why this was happening. The root cause
On Oct 25, 2005, at 2:33 AM, Joe Orton wrote:
On Mon, Oct 24, 2005 at 03:33:17AM -, Brian Pane wrote:
Author: brianp
Date: Sun Oct 23 20:33:14 2005
New Revision: 327945
URL: http://svn.apache.org/viewcvs?rev=327945view=rev
Log:
Async write completion for Event MPM
(backported from async
APR_EGENERAL;
}
It looks like the new core output filter is messing up the blocking mode
when it's called during the sending of the request to the origin server.
I'll continue tracking this down tomorrow.
Brian
On Oct 25, 2005, at 7:06 PM, Brian Pane wrote:
On Oct 25, 2005, at 2:33 AM, Joe Orton
On Oct 25, 2005, at 2:33 AM, Joe Orton wrote:
httpd-test runs against the trunk are failing all over the place
today,
I guess caused by one of these changes...
prefork is failing like:
Failed TestStat Wstat Total Fail Failed List of
Failed
On Oct 10, 2005, at 5:15 PM, Greg Ames wrote:
- event-ize lingering close. it eats up roughly the same number of
worker threads as synchronous writes for SPECweb99.
Is this because the lingering close is waiting a while for the client to
close the inbound side of the connection? Or is the
On Oct 18, 2005, at 7:11 AM, Greg Ames wrote:
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
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.
Brian
On Oct 13, 2005, at 11:36 AM, Brian Akins wrote:
Greg Ames wrote:
this is interesting to me
Tested successfully on Linux 2.6.13/x86_64 (Fedora Core 4) with
both worker and prefork MPMs.
I encountered lots of errors in perl-framework's t/TEST with prefork
on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
are due to httpd-2.0.55 problems or just problems with my Perl
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. Once an entire response has been
generated and passed to the output filter chain, the MPM's
poller/listener thread watches the connection for
On Oct 10, 2005, at 2:22 AM, Graham Leggett wrote:
Brian Pane said:
I encountered lots of errors in perl-framework's t/TEST with prefork
on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
are due to httpd-2.0.55 problems or just problems with my Perl
installation.
I ran
On Oct 10, 2005, at 7:32 AM, William A. Rowe, Jr. wrote:
Brian Pane wrote:
I encountered lots of errors in perl-framework's t/TEST with prefork
on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
are due to httpd-2.0.55 problems or just problems with my Perl
installation
On Oct 10, 2005, at 12:01 AM, Paul Querna wrote:
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. Once an entire response has been
generated and passed to the output filter
On Oct 9, 2005, at 3:25 AM, Nick Kew wrote:
On Sunday 09 October 2005 02:37, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewcvs?rev=307339view=rev
Log:
Redesign of request cleanup:
- A new End-Of-Request bucket is pushed through the output filter
chain after the last bucket
On Oct 9, 2005, at 11:41 AM, Nick Kew wrote:
On Sunday 09 October 2005 18:49, Brian Pane wrote:
On Oct 9, 2005, at 3:25 AM, Nick Kew wrote:
On Sunday 09 October 2005 02:37, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewcvs?rev=307339view=rev
Log:
Redesign of request cleanup
On Oct 5, 2005, at 7:04 PM, William A. Rowe, Jr. wrote:
Before I consider backporting for 2.1-dev, I'd very much appreciate
if some of the event mpm ap_process_http_async_connection developers
would confirm that the mechanisms behave the way I expect them to.
IIUC, the event pollset will
On Sep 30, 2005, at 11:19 AM, William A. Rowe, Jr. wrote:
Linux, Win32 and Netware begin their new socket's life in a blocking
state, while Solaris and AIX begin their life in a non-blocking state.
[...]
Do we want to;
* Fix mod_echo with this gross little hack? (and leave it to each
I just committed a new version of ap_core_output_filter() to the
async-dev branch.
The semantics of the filter have changed in a fundamental way: the
original version
does blocking writes and usually tries to write out all of the
available data before
writing (except in cases where it
On Sep 16, 2005, at 6:19 PM, Greg Ames wrote:
I see a tiny difference from the current event MPM implementation.
a new connection initially goes into CONN_STATE_READ_REQUEST_LINE.
it could easily be done as drawn too...the decision was almost a
toss up. but since several OSes have some
On Sep 9, 2005, at 4:25 PM, Brian Pane wrote:
This weekend, when I have time to do some more httpd work, I'll do
a more
robust hack of the leader MPM within the async-dev branch so that it's
available for other people to test.
Just committed... This version is a bit slower than the worker
Colm MacCarthaigh wrote:
On Fri, Sep 09, 2005 at 04:18:34PM -0400, Bill Stoddard wrote:
I guess for some definition of much I am not suprised. I would expect the
event MPM to consume more CPU than worker under 'low' workloads (low number
of concurrent clients) because it's making more
Torsten Foertsch wrote:
On Tuesday 06 September 2005 06:10, Brian Pane wrote:
http://www.brianp.net/work/opensource/apache/async.html
Shouldn't there be a transition from HANDLER to CHECK_REQUEST_LINE_READABLE in
case the full response is sent and keep-alive is on?
Yes, good
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.
Comments welcome... Am I missing any state transitions (particularly
for error
On Sep 5, 2005, at 9:17 AM, Paul Querna wrote:
Right now, I am trying to understand the implications of a Handler
state. It says we only shift states from Handler - Write Completion
once we have the 'Full Request Generated'. So does this mean the
Handler will write to the client at all?
Yes,
On Sep 5, 2005, at 5:21 AM, Ian Holsman wrote:
are you missing the case where the client disconnects mid-request
(CONN_STATE_READ_REQUEST_LINE - Connection_deleted)
and when the client disconnects mid-response?
CONN_STATE_HANDLER/CONN_STATE_WRITE_COMPLETION - Connection_deleted)
case where
I've prototyped a modification to the event MPM that uses a (mostly)
nonblocking
output filter in place of ap_core_output_filter().
This patch adds a new connection state, CONN_STATE_WRITE_COMPLETION.
The new network-level filter, event_output_filter(), does nonblocking
writes
(except when
On Sep 4, 2005, at 1:42 PM, Paul Querna wrote:
So, here is a hackish patch to allow easier building of custom core
output filters, for places like the Event MPM.
It uses the APR optional functions to optionally register a
function to
replace the C-O-F.
Thanks, that's a bit cleaner than
On Sep 4, 2005, at 4:26 PM, Paul Querna wrote:
I am thinking we should create a svn branch to flesh out some of these
ideas?
How does 'branches/async-dev' sound to you?
+1. I'd also be comfortable doing work under server/mpm/experimental
in the 2.3 trunk and then refactoring it up into the
The attached patch delays the setting of TCP_NODELAY on client
connections
until the first time core_output_filter has to do a writev_it_all()
or emulate_sendfile().
My motivation for this is to work around the TCP_NODELAY/TCP_CORK
problem
in Linux 2.6. However, it also will save a couple
On Aug 26, 2005, at 12:55 AM, Joe Orton wrote:
On Fri, Aug 26, 2005 at 12:42:19AM -0700, Brian Pane wrote:
The attached patch delays the setting of TCP_NODELAY on client
connections until the first time core_output_filter has to do a
writev_it_all() or emulate_sendfile(). My motivation
On Aug 26, 2005, at 1:59 AM, Joe Orton wrote:
On Fri, Aug 26, 2005 at 01:23:15AM -0700, Brian Pane wrote:
I didn't think it was actually possible for APR to allow TCP_CORK and
TCP_NODELAY
at the same time. From the tcp(7) manual page on my FC4
installation,
That's out of date yes
There was some discussion a few weeks ago about whether TCP_CORK was
broken on Linux 2.6.
I did some tests on Linux 2.6.12 and found that TCP_CORK *does*
appear to
work. However, it doesn't work if TCP_NODELAY is also set on the
socket (as
the tcp(7) manual page warns).
I've attached my
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 http_request.c, a
On Jul 19, 2005, at 12:55 PM, William A. Rowe, Jr. wrote:
Greg and a few others voiced interest in moving from null-term
strings to counted strings for a future version of Apache.
This was too broad a scope change to make it into 2.0, of course,
and was dropped on the floor for the time being.
On Jul 7, 2005, at 11:26 AM, Jim Jagielski wrote:
I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.
+1
Brian
On Jul 3, 2005, at 11:27 PM, Paul Querna wrote:
Brian Pane wrote:
I spent some time today profiling the latest httpd-2.1 trunk on OS X,
Which version of APR? The shared library names make it sound like APR
1.0.0, not APR/APR-Util trunk?
I was using the latest trunk of APR APR-Util
Brian Pane wrote:
Richard Jones wrote:
On Thu, Nov 25, 2004 at 04:00:46PM -0800, Brian Pane wrote:
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few
days.
Any chance of integrating the fix in bug 27550
Justin Erenkrantz wrote:
--On Sunday, November 28, 2004 3:36 PM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
Meanwhile, now that we have the latest release of PCRE in httpd-2.1, one
option would help somewhat would be to backport it into httpd-2.0.
I doubt we'd be able to maintain binary
Joe Orton wrote:
On Fri, Nov 26, 2004 at 11:55:35PM -0800, Brian Pane wrote:
Yep. I just did that, and it worked as expected. I ended up with a
clean merge: the only files that needed merge conflict resolution were
those that had been modified in the srclib/pcre copy:
Looks good
Brad Nicholes wrote:
While trying to get NetWare to build with the new PCRE update, I
noticed that there is a duplicate of pcreposix.h in both include/ and
srclib/pcre/ directories. Currently they don't match which is causing
the NetWare build to break. I can sync them up, but the real
Richard Jones wrote:
On Thu, Nov 25, 2004 at 04:00:46PM -0800, Brian Pane wrote:
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few days.
Any chance of integrating the fix in bug 27550 at the same time
Ian Holsman wrote:
hi.
I'm building from a clean slate (new box) and am having issues
building it.
It seems not to be including the stuff in listen.c
its OS/X 10.3.6 with november's gcc patch.. no fink on it either.
I just did a build from a clean SVN checkout on 10.3.6, and it worked.
I was
This commit message bounced because it exceeded the mailer daemon's size
limit.
Here's the list of changed files. You can see the details of the diffs via the
link below.
Brian
Author: brianp
Date: Fri Nov 26 23:28:04 2004
New Revision: 106690
URL:
Joe Orton wrote:
I also spent some time recently working out how to apply that process to
srclib/pcre and it seemed fairly straight-forward. It seems like the
process works OK even if the step to copy the original vendor
pcre/current to srclib/pcre is skipped, so the current srclib/pcre can
be
I found that the configure.in in recent releases of PCRE uses some
autoconf macros that won't work unless aclocal is called first to
produce a proper aclocal.m4: AC_PROG_LIBTOOL and AC_LIBTOOL_WIN32_DLL
This buildconf patch fixes it for me (and works with both the new PCRE
5.0 and the old
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few days.
One question, though...
I'd like to follow the vendor-branch approach outlined in the Subversion
book, http://svnbook.red-bean.com/en/1.0/ch07s04.html.
Paul Querna wrote:
Is there any reason to keep libpcre in the httpd tree?
I believe we should use the PCRE installed on the system. If its not
on the system, the user can install it. There are several bugs from
3rd party modules that also try to use pcre, and get conflicting
symbols because
Paul Querna wrote:
Brian Akins wrote:
Paul Querna wrote:
[...]
Have you tried it with higher number of clients -- i.e,. -c 1024?
Nope. I was already maxing out my 100mbit LAN at 25 clients. I don't
have a good testing area for static content request benchmarking.
I am thinking of trying to
Paul Querna wrote:
Paul Querna wrote:
A thread per-connection that is currently being processed.
Note that this is not the traditional 'event' model that people write
huge papers about and thttpd raves about, but rather a hybrid that
uses a Worker Thread todo the processing, and a single
Henri Gomez wrote:
I made some benchs on my Linux Fedora Core 2
on a P4 2.8ghz / 1Gb RAM :
Apache 2 alone 1202 req/s
TC/Coyote 883 req/s
One thing I noticed when looking at Tomcat 5.0.x is that its default,
static-file-delivering servlet does a stat(2) of each path prefix leading
Brian Akins wrote:
I'm writing an optimized caching module. I've been using 2.0.50.
Here are the top 50 from oprofile ( http://oprofile.sourceforge.net/ ):
Linux cnnsquid2 2.6.7-cnn.1smp #1 SMP Wed Jun 16 13:41:14 EDT 2004
x86_64 x86_64 x86_64 GNU/Linux
Using leader mpm. I patched
Nick Kew wrote:
On Sun, 27 Jun 2004, Paul Querna wrote:
The 2.0 branch was made over 18 months ago, it is time to make another
stable branch. I believe many people want the AAA changes, and it brings
even more features to encourage people to upgrade from 1.3.
There's another consideration
On Jun 2, 2004, at 12:40 PM, Brian Akins wrote:
AFAIK, the linux x86 atomic stuff can be used unchanged on Linux
x86_64. This is based on my digging in the kernel source. All the
functions apr uses are identical.
Should I submit a patch?
Sure, sounds like a good thing to add.
Thanks,
Brian
On Apr 21, 2004, at 9:11 AM, Sumeet Singh wrote:
Hi,
In my use-case I am dealing with multiple headers with the same key
(e.g. Cookie), and need to modify or remove a specific header based on
its key and value (e.g. remove a certain cookie header while leaving
the rest in). There is no api
On Apr 21, 2004, at 9:11 AM, Sumeet Singh wrote:
Hi,
In my use-case I am dealing with multiple headers with the same key
(e.g. Cookie), and need to modify or remove a specific header based on
its key and value (e.g. remove a certain cookie header while leaving
the rest in). There is no api
On Mar 12, 2004, at 11:01 AM, Andre Breiler wrote:
Hi,
On Fri, 12 Mar 2004, Brian Pane wrote:
That definitely sounds useful. I think you can get the same effect,
though, by using the existing 2.0/2.1 mod_include hook to add new
directives... something like this:
!--#set_random var=blah
That definitely sounds useful. I think you can get the same effect,
though, by using the existing 2.0/2.1 mod_include hook to add new
directives... something like this:
!--#set_random var=blah min=$min max=$max --
That's not quite as syntactically elegant, but it has the advantage
of not
On Dec 10, 2003, at 5:15 PM, Cliff Woolley wrote:
On Wed, 10 Dec 2003, Stas Bekman wrote:
But doesn't unsetting the C-L header cause the C-L filter to
automatically
attempt to generate a new C-L value?
Not unless the C-L filter sees the entire response in the first brigade
passed through it.
On Dec 4, 2003, at 9:18 AM, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
[SNIP]
On Wed, 3 Dec 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
instead of having the worker threads compete for the
incoming
Ben Hyde wrote:
In this discussion people have been making two kinds of lists. The
list of hypothetical reasons why activity seems to be petering out.
The list of possible cures for those hypothetical ills.
We need a third list. A list of fun hacks that 2.0 enables.
It would be good to
On Tue, 2002-10-15 at 10:31, Bill Stoddard wrote:
Something I've been hacking on (in the pejorative sense of the word 'hack'.
Look at the patch and you will see what I mean :-). This should apply and
serve pages on Linux, though the event_loop is clearly broken as it does not
timeout
This appears to be due to the code at line ~2961 of
mod_include.c that tries to delete buckets from *bb
until it hits the bucket where the next tag starts.
In this test case, the bucket where the next tag
starts isn't in *bb at all; it's in ctx-ssi_tag_brigade.
I'm evaluating a couple of potential
On Wed, 2003-06-18 at 14:22, Sebastian Abt wrote:
Hi all,
I'm currently writing an Apache module (Apache 1.3.27) for virtual
masshosting based on a SQL backend (currently MySQL later on
PostgreSQL). Therefore I'm searching for information about the
differences between requests
On Sat, 2003-06-14 at 22:47, Joe Schaefer wrote:
Brian Pane [EMAIL PROTECTED] writes:
Committed, thanks.
Brian
On Sun, 2003-06-08 at 22:46, Joe Schaefer wrote:
[...]
diff -u -r1.76 util_filter.h
--- include/util_filter.h 3 Feb 2003 17:52:54 - 1.76
It depends on your operating system. If you're running Solaris,
try /usr/proc/bin/pstack pid-of-the-hung process to get a stack
trace of every thread. On Linux, you may be able to get some
info with gdb (how well this works depends on kernel, libc, and
gdb versions). For other OSs, hopefully
Committed, thanks.
Brian
On Sun, 2003-06-08 at 22:46, Joe Schaefer wrote:
Justin Erenkrantz [EMAIL PROTECTED] writes:
[...]
Doc patches welcomed to make it more explicit. -- justin
Index: include/util_filter.h
===
RCS
On Mon, 2003-03-31 at 00:38, Justin Erenkrantz wrote:
--On Monday, March 31, 2003 1:56 AM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Please test this 2.0.45-alpha candidate for general release within the
next 24 hours. Once the dev@ list receives enough positive feedback,
we
1 - 100 of 586 matches
Mail list logo
