PATCH: lazy initialization of TCP_NODELAY (workaround for 2.6 TCP_CORK problem)

[Brian Pane]

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 of syscalls for  
any request that

is handled with sendfile(2).

Note that there was an APR bug that caused TCP_NODELAY to be set on the
listener socket at startup as a side-effect of TCP_DEFER_ACCEPT being  
set.
I just committed a fix for this.  Without that fix, Linux 2.6 systems  
using this httpd

patch will still exhibit the corking problem.

Can a couple of volunteers please test and/or review this patch?  I'd  
appreciate
a second opinion before I commit, given the subtlety of the NODELAY  
and CORK

semantics on various platforms.

Thanks,
Brian
Index: server/core.c
===
--- server/core.c   (revision 240169)
+++ server/core.c   (working copy)
@@ -3827,25 +3827,6 @@
 {
 core_net_rec *net = apr_palloc(c->pool, sizeof(*net));
 
-#ifdef AP_MPM_DISABLE_NAGLE_ACCEPTED_SOCK
-apr_status_t rv;
-
-/* The Nagle algorithm says that we should delay sending partial
- * packets in hopes of getting more data.  We don't want to do
- * this; we are not telnet.  There are bad interactions between
- * persistent connections and Nagle's algorithm that have very severe
- * performance penalties.  (Failing to disable Nagle is not much of a
- * problem with simple HTTP.)
- */
-rv = apr_socket_opt_set(csd, APR_TCP_NODELAY, 1);
-if (rv != APR_SUCCESS && rv != APR_ENOTIMPL) {
-/* expected cause is that the client disconnected already,
- * hence the debug level
- */
-ap_log_cerror(APLOG_MARK, APLOG_DEBUG, rv, c,
-  "apr_socket_opt_set(APR_TCP_NODELAY)");
-}
-#endif
 net->c = c;
 net->in_ctx = NULL;
 net->out_ctx = NULL;
Index: server/listen.c
===
--- server/listen.c (revision 240164)
+++ server/listen.c (working copy)
@@ -126,10 +126,6 @@
 }
 }
 
-#if APR_TCP_NODELAY_INHERITED
-ap_sock_disable_nagle(s);
-#endif
-
 if ((stat = apr_socket_bind(s, server->bind_addr)) != APR_SUCCESS) {
 ap_log_perror(APLOG_MARK, APLOG_STARTUP|APLOG_CRIT, stat, p,
   "make_sock: could not bind to address %pI",
Index: server/core_filters.c
===
--- server/core_filters.c   (revision 240164)
+++ server/core_filters.c   (working copy)
@@ -887,6 +887,10 @@
 else
 #endif
 {
+#ifdef AP_MPM_DISABLE_NAGLE_ACCEPTED_SOCK
+(void)apr_socket_opt_set(net->client_socket,
+ APR_TCP_NODELAY, 1);
+#endif
 rv = emulate_sendfile(net, fd, &hdtr, foffset, flen,
   &bytes_sent);
 }
@@ -898,7 +902,9 @@
 }
 else {
 apr_size_t bytes_sent;
-
+#ifdef AP_MPM_DISABLE_NAGLE_ACCEPTED_SOCK
+(void)apr_socket_opt_set(net->client_socket, APR_TCP_NODELAY, 1);
+#endif
 rv = writev_it_all(net->client_socket,
vec, nvec,
nbytes, &bytes_sent);

re: ap_process_connection

[C.G. Lee]

>Where is this function implemented? I can't seem to find it.
 
When I was exploring the Apache2 source code, I couldn't understand the ap_process_connection(). Why is it there? What does it doing??  
 
I don't know what you're doing, but the function ap_process_connection is in the server/connection.c. 
 
		 
 

   

   무료 1GB용량!, 더이상 용량 고민없는 야후! 메일을 써보세요.
 
  
   

 
  


   
 
   

	  
	
	  
	 
  
 
 
  대한민국 블로그가 모인 곳! 
  피플링에서 네이버, 이글루스를 만나다 
 
   
 
   
   
   
   
  
 
  
 
   

 
  야후! 모바일 
  최신 휴대폰 정보, 벨소리, 캐릭터, 문자메세지 

  

  

  

  

Re: PATCH: lazy initialization of TCP_NODELAY (workaround for 2.6 TCP_CORK problem)

[Joe Orton]

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 for this is to 
> work around the TCP_NODELAY/TCP_CORK problem in Linux 2.6.  However, 
> it also will save a couple of syscalls for any request that is handled 
> with sendfile(2).

This will actually end up being *more* expensive on 2.6 systems in the 
long run, though, right?  I'm not convinced this is a good idea.  With 
APR changed to allow setting TCP_CORK and TCP_NODELAY at the same time 
with 2.6, it is cheaper to just set TCP_NODELAY once on the listening 
socket and never have to touch it again.

> Note that there was an APR bug that caused TCP_NODELAY to be set on 
> the listener socket at startup as a side-effect of TCP_DEFER_ACCEPT 
> being set.

good catch!

joe

Re: PATCH: lazy initialization of TCP_NODELAY (workaround for 2.6 TCP_CORK problem)

[Brian Pane]

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 for this is to
work around the TCP_NODELAY/TCP_CORK problem in Linux 2.6.  However,
it also will save a couple of syscalls for any request that is  
handled

with sendfile(2).



This will actually end up being *more* expensive on 2.6 systems in the
long run, though, right?  I'm not convinced this is a good idea.  With
APR changed to allow setting TCP_CORK and TCP_NODELAY at the same time
with 2.6, it is cheaper to just set TCP_NODELAY once on the listening
socket and never have to touch it again.


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,

   TCP_CORK
  If set, don’t send  out  partial  frames.   All   
queued  partial
  frames  are sent when the option is cleared again.   
This is use-
  ful for prepending headers before calling  sendfile 
(2),  or  for
  throughput  optimization.   This  option cannot be  
combined with
  TCP_NODELAY.  This option should not be used in code  
intended to

  be portable.

and

   TCP_NODELAY
  If  set,  disable the Nagle algorithm.  This means  
that segments
  are always sent as soon as possible, even if  there   
is  only  a
  small  amount  of  data.   When  not set, data is  
buffered until
  there is a sufficient amount to send out, thereby   
avoiding  the
  frequent  sending  of  small packets, which results in  
poor uti-
  lization of the network.  This option cannot be used  
at the same

  time as the option TCP_CORK.

Is the manpage out of date?

If it's possible to use both TCP_CORK and TCP_NODELAY on the same
socket in 2.6.13 or later (assuming that's when the fix for the current
NODELAY toggling problem becomes available), then yes, my lazy
evaluation approach will be less efficient than just setting TCP_NODELAY
on the listener socket--for requests that don't use sendfile.  For  
requests

that do use sendfile, I think the logic implemented by my patch will be
optimal for both 2.6.1-2.6.12 and 2.6.13+

Brian

DO NOT REPLY [Bug 36370] New: - mod_aspdotnet不支持dotnet的cookieless模式

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36370

   Summary: mod_aspdotnet不支持dotnet的cooki
eless模式
   Product: Apache mod_aspdotnet
   Version: 2.0.0
  Platform: Other
OS/Version: Windows Server 2003
Status: NEW
  Severity: normal
  Priority: P2
 Component: mod_aspdotnet
AssignedTo: cli-dev@httpd.apache.org
ReportedBy: [EMAIL PROTECTED]


我用dotnet建了一个MobileWEBApplication,把它的web.config里的cookieless=true
测试时访问:
http://localhost/test/default.aspx
正常情况下(用IIS时)会重定向到:
http://localhost/test/(fj13mf2pdjnjrcnrb41sun55)/default.aspx
IIS会对此进行处理。
mod_aspdotnet + apache则会报错:
Not Found

The requested URL /test/(fj13mf2pdjnjrcnrb41sun55)/default.aspx was not found 
on 
this server.
Apache Server at localhost Port 80

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

style update part III

[Philip M. Gollucci]

Hi all,

This transposes
my (
with
my(

per the style guide for mod_perl perl code.

I don't think I've commited anything to A-T yet, does the same style guide
apply?

See attached.


--
END

What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
  http://www.liquidityservicesinc.com
   http://www.liquidation.com
   http://www.uksurplus.com
   http://www.govliquidation.com
   http://www.gowholesale.com
Index: lib/Apache/TestRun.pm
===
--- lib/Apache/TestRun.pm   (revision 240189)
+++ lib/Apache/TestRun.pm   (working copy)
@@ -1051,7 +1051,7 @@
 }
 
 sub check_perms {
-my ($self, $user, $uid, $gid) = @_;
+my($self, $user, $uid, $gid) = @_;
 
 # test that the base dir is rwx by the selected non-root user
 my $vars = $self->{test_config}->{vars};
@@ -1104,7 +1104,7 @@
 # they better be with the same permissions. dropping root permissions
 # and becoming the same user as the server side solves this problem.
 sub become_nonroot {
-my ($self, $user, $uid, $gid) = @_;
+my($self, $user, $uid, $gid) = @_;
 
 warning "the client side drops 'root' permissions and becomes '$user'";
 
@@ -1249,7 +1249,7 @@
 # generate t/TEST script (or a different filename) which will drive
 # Apache::TestRun
 sub generate_script {
-my ($class, @opts) = @_;
+my($class, @opts) = @_;
 
 my %opts = ();
 
Index: lib/Apache/TestConfigC.pm
===
--- lib/Apache/TestConfigC.pm   (revision 240189)
+++ lib/Apache/TestConfigC.pm   (working copy)
@@ -157,7 +157,7 @@
 }
 
 sub cmodules_write_makefile {
-my ($self, $mod) = @_;
+my($self, $mod) = @_;
 my $write = \&{"cmodules_write_makefile_$^O"};
 $write = \&cmodules_write_makefile_default unless defined &$write;
 $write->($self, $mod);
Index: lib/Apache/TestReport.pm
===
--- lib/Apache/TestReport.pm(revision 240189)
+++ lib/Apache/TestReport.pm(working copy)
@@ -32,7 +32,7 @@
 # generate t/REPORT script (or a different filename) which will drive
 # Apache::TestReport
 sub generate_script {
-my ($class, $file) = @_;
+my($class, $file) = @_;
 
 $file ||= catfile 't', 'REPORT';
 
Index: lib/Apache/TestConfigPHP.pm
===
--- lib/Apache/TestConfigPHP.pm (revision 240189)
+++ lib/Apache/TestConfigPHP.pm (working copy)
@@ -29,7 +29,7 @@
 
 @Apache::TestConfigPHP::ISA = qw(Apache::TestConfig);
 
-my ($php_ini, $test_more);
+my($php_ini, $test_more);
 
 {
   # __DATA__ contains both php.ini and test-more.php
@@ -63,7 +63,7 @@
 );
 
 sub warn_style_sub_ref {
-my ($self, $filename) = @_;
+my($self, $filename) = @_;
 my $ext = $self->filename_ext($filename);
 return $warn_style{ $file_ext{$ext} || 'default' };
 }
@@ -190,7 +190,7 @@
 my %seen = ();
 
 for my $entry (@entries) {
-my ($file, $module, $subdir, $status) = @$entry;
+my($file, $module, $subdir, $status) = @$entry;
 
 my @args = ();
 
Index: lib/Apache/TestConfigPerl.pm
===
--- lib/Apache/TestConfigPerl.pm(revision 240189)
+++ lib/Apache/TestConfigPerl.pm(working copy)
@@ -491,7 +491,7 @@
 $self->configure_pm_tests_sort([EMAIL PROTECTED]);
 
 for my $entry (@entries) {
-my ($file, $module, $subdir, $status) = @$entry;
+my($file, $module, $subdir, $status) = @$entry;
 my @args = ();
 
 my $directives = $self->add_module_config($file, [EMAIL PROTECTED]);
@@ -552,7 +552,7 @@
 
 # scan tests for interesting information
 sub run_apache_test_config_scan {
-my ($self, $file) = @_;
+my($self, $file) = @_;
 
 my @status = ();
 $status[APACHE_TEST_CONFIGURE]= 0;
@@ -586,7 +586,7 @@
 # the slurped file in.  and if APACHE_TEST_CONFIGURE has been found we
 # require the file and run this function.
 sub run_apache_test_configure {
-my ($self, $file, $module, $status) = @_;
+my($self, $file, $module, $status) = @_;
 
 return unless $status->[APACHE_TEST_CONFIGURE];
 
Index: lib/Apache/TestMB.pm
===
--- lib/Apache/TestMB.pm(revision 240189)
+++ lib/Apache/TestMB.pm(working copy)
@@ -104,7 +104,7 @@
 }
 
 sub _cmodules {
-my ($self, $action) = @_;
+my($self, $action) = @_;
 die "The cmodules" . ( $action ne 'all' ? "_$action" : '')
   . " action is not yet implemented";
 # XXX TBD.
Index: lib/Apache/TestConfig.pm
===

Re: PATCH: lazy initialization of TCP_NODELAY (workaround for 2.6 TCP_CORK problem)

[Joe Orton]

On Fri, Aug 26, 2005 at 01:23:15AM -0700, Brian Pane wrote:
> 
> 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 for this is to
> >>work around the TCP_NODELAY/TCP_CORK problem in Linux 2.6.  However,
> >>it also will save a couple of syscalls for any request that is  
> >>handled
> >>with sendfile(2).
> >>
> >
> >This will actually end up being *more* expensive on 2.6 systems in the
> >long run, though, right?  I'm not convinced this is a good idea.  With
> >APR changed to allow setting TCP_CORK and TCP_NODELAY at the same time
> >with 2.6, it is cheaper to just set TCP_NODELAY once on the listening
> >socket and never have to touch it again.
> 
> 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, see recent thread ;)

All 2.6.x kernels do allow setting both TCP_CORK and TCP_NODELAY at the 
same time.

All current 2.6.x kernels have the bug in TCP_CORK handling which means 
that if TCP_NODELAY was ever enabled on the socket, TCP_CORK will not 
take effect.

The fix for that was in the 2.6.13-rc7 release, for the curious: 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=89ebd197eb2cd31d6187db344d5117064e19fdde

...
> If it's possible to use both TCP_CORK and TCP_NODELAY on the same
> socket in 2.6.13 or later (assuming that's when the fix for the current
> NODELAY toggling problem becomes available), then yes, my lazy
> evaluation approach will be less efficient than just setting TCP_NODELAY
> on the listener socket--for requests that don't use sendfile.
> For requests that do use sendfile, I think the logic implemented by my 
> patch will be optimal for both 2.6.1-2.6.12 and 2.6.13+

To be clear this is only a partial workaround for the kernel bug: if at 
any time something is sent on the connection which requires enabling 
TCP_NODELAY, any subsequent TCP_CORKs will have no effect.

Given that fact I'm not convinced it's worth changing httpd: this is (1) 
a kernel bug and (2) an APR lack-of-feature; with both of those things 
fixed the current httpd code is perfectly correct.

joe

Re: mod_include features request

[Graham Leggett]

Weiss said:

> As it looks like mod_include isn't changing a lot, but some new features
> could be implemented there and would suite well.
>
> - Smart and efficient server-side caching mechanism! (extremly useful in
> static sites but also for headers and footers that include many other
> static files).

mod_cache and friends should be able to help with this, most of what you
describe has already been implemented, however teaching mod_include to add
mod_cache into the mod_include subrequests is an idea that is definitely
worth investigating.

Regards,
Graham
--

Re: mod_include features request

[Nick Kew]

On Friday 26 August 2005 10:11, Graham Leggett wrote:
> Weiss said:
> > As it looks like mod_include isn't changing a lot, but some new features
> > could be implemented there and would suite well.
> >
> > - Smart and efficient server-side caching mechanism! (extremly useful in
> > static sites but also for headers and footers that include many other
> > static files).
>
> mod_cache and friends should be able to help with this, most of what you
> describe has already been implemented, however teaching mod_include to add
> mod_cache into the mod_include subrequests is an idea that is definitely
> worth investigating.

mod_include is a little less than thorough.  With xbithack, it'll check the 
page's last modification time to make it cacheable.  But it won't propagate
the checks to the included content.

A make-like scheme in mod_include would let it work better with mod_cache.

-- 
Nick Kew

Re: ap_process_connection

[Phillip Susi]

Except that it isn't REALLY defined there.  The use of all these macros
is giving me a headache.  There are a number of papers out there on why
this kind of macro (ab)use is bad, mainly because it makes it impossible
to understand the code.

server/connection.c has this:

AP_IMPLEMENT_HOOK_RUN_FIRST(int,process_connection,(conn_rec
*c),(c),DECLINED)

Well what the heck does that do?  There's no function body defined
there.  I'm guessing that macro does some tricks to achieve something
like polymorphism in C, binding an object to a set of functions that
should be called in a given event.  I can't see what function is being
bound to the process_connection event though.

When I looked up the definition of this macro, it is itself defined
using another macro.  My eyes have now gone crossed.  Maybe I'll try to
understand these evil macros later.

C.G. Lee wrote:
>  >Where is this function implemented? I can't seem to find it.
>  
> When I was exploring the Apache2 source code, I couldn't understand the 
> ap_process_connection(). Why is it there? What does it doing?? 
>  
> I don't know what you're doing, but the function ap_process_connection 
> is in the server/connection.c.
>  
> 

Re: PATCH: lazy initialization of TCP_NODELAY (workaround for 2.6 TCP_CORK problem)

[Brian Pane]

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, see recent thread ;)

All 2.6.x kernels do allow setting both TCP_CORK and TCP_NODELAY at  
the

same time.

All current 2.6.x kernels have the bug in TCP_CORK handling which  
means

that if TCP_NODELAY was ever enabled on the socket, TCP_CORK will not
take effect.

The fix for that was in the 2.6.13-rc7 release, for the curious:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/ 
linux-2.6.git;a=commit;h=89ebd197eb2cd31d6187db344d5117064e19fdde




Ah, thanks.  With this kernel fix forthcoming, the current httpd  
implementation
(sans my patch) will do the right thing for both sendfile and non- 
sendfile responses.


Brian

Conflict in authorization types among various authz modules...

[Brad Nicholes]

   I am looking for comments from those who helped to implement the
refactored authentication model and those who helped restructure the
authentication modules.  

   One of the problems that I discovered while working on the
restructuring of the authnz_ldap module was the name space for the
authorization types.  I found that the 2.0 version of mod_auth_ldap
implemented authorization types such as "valid-user", "user" and
"group".  After creating mod_authnz_ldap and restructuring the ldap
authorization types, I found that using these authorization type names
conflicted with mod_authz_user and mod_authz_groupfile.  Meaning that if
mod_authnz_ldap was loaded along side of mod_authz_user or
mod_authz_groupfile, the authorization module that actually attempted to
handle authorization was at the mercy of the module load order and in
most cases was wrong.  In other words, the following configuration would
not be able to accurately determine which authz module should be
handling authorization. 

LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule authz_user_module modules/mod_authz_user.so


...
require user bnicholes


To resolve this issue I prefixed the ldap authorization types with
"ldap-".  

   Looking through the authorization types for the other authz modules
I noticed that there are other similar conflicts.

mod_authz_dbm file-group, group
mod_authz_groupfile file-group, group
mod_authz_owner file-group

I would propose that the following renaming or elimination of types
should be done before Apache 2.2 is released in order to resolve the
conflicts

mod_authz_dbmdbm-group
mod_authz_groupfile group
mod_authz_owner file-group


Comments?

Brad

Re: svn commit: r240270 - in /httpd/httpd/trunk: CHANGES server/mpm/prefork/mpm.h server/mpm/prefork/prefork.c

[Colm MacCarthaigh]

I decided to do prefork first, since it seems the more complicated out
of the MPM's to stop gracefully. I've tested locally, using

#!/bin/sh

echo "Content-type: text/plain"
echo

while true; do
sleep 1
date
done

as my ultra-sophisticated long-lived download, however I would be amazed
if running two instances of httpd concurrently does not break some
things (esp third party modules which use some kind of lockfile or
on-disk state). So, heads up there on any trunk-runners.

I'm going to add yet more documentation to stopping.xml, to describe
those kind of issues.

On Fri, Aug 26, 2005 at 04:09:58PM -, [EMAIL PROTECTED] wrote:
> Author: colm
> Date: Fri Aug 26 09:09:54 2005
> New Revision: 240270
> 
> URL: http://svn.apache.org/viewcvs?rev=240270&view=rev
> Log:
> 
> Implement a "graceful-stop" for the prefork MPM (might aswell do the hard one
> first). 
> 
> General approach is to send SIGUSR1 to all children (which will de-listen, and
> exit when finished), and to gather all children as they exit. 
> 
> We don't use a sleep(timeout) for the timeout implementation, because this
> would lead to a rut of defunct children until the timeout had expired.
> 
> set_graceful_shutdown stolen from Ken Coar. See <[EMAIL PROTECTED]>
> (28 Mar 2003).
> 
> 
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/server/mpm/prefork/mpm.h
> httpd/httpd/trunk/server/mpm/prefork/prefork.c
-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]

Status of PR 29528? (Memory leaks in mod_cgid)

[Justin Erenkrantz]

I just had to upgrade my personal server to Solaris 10.  With 2.0.54, I'm now 
getting the mod_cgid process (Worker MPM) taking up GBs of memory.  Eek.


The closest PR I can find is 29528.



In it, Joe said he had some patches to fix some leaks and that he would be 
collecting them.  But, that was last year and I'm not sure if they've ever 
made it anywhere.  So, does anyone know if these problems are fixed?


Do I need to go bug-huntin'?  =)  Thanks!  -- justin

Re: Status of PR 29528? (Memory leaks in mod_cgid)

[Joe Orton]

On Fri, Aug 26, 2005 at 10:03:55AM -0700, Justin Erenkrantz wrote:
> I just had to upgrade my personal server to Solaris 10.  With 2.0.54, I'm 
> now getting the mod_cgid process (Worker MPM) taking up GBs of memory.  Eek.

That sounds more like:

http://issues.apache.org/bugzilla/show_bug.cgi?id=34264

> The closest PR I can find is 29528.
> 
> 
> 
> In it, Joe said he had some patches to fix some leaks and that he would be 
> collecting them.  But, that was last year and I'm not sure if they've ever 
> made it anywhere.  So, does anyone know if these problems are fixed?

I don't think there's anything left in that PR which is not covered by

http://issues.apache.org/bugzilla/show_bug.cgi?id=23567

the original report in 29528 was the Content-Range handling thing which 
got fixed a while ago, I think I'll close that one now.

joe

Re: Status of PR 29528? (Memory leaks in mod_cgid)

[Jeff Trawick]

On 8/26/05, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 26, 2005 at 10:03:55AM -0700, Justin Erenkrantz wrote:
> > I just had to upgrade my personal server to Solaris 10.  With 2.0.54, I'm
> > now getting the mod_cgid process (Worker MPM) taking up GBs of memory.  Eek.
> 
> That sounds more like:
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34264

Right.  If you must use mod_cgid on Solaris 10, go back to the next to
last Solaris Express driver prior to GA ;)  Recently I applied the
latest Solaris 10 updates and retested, without success.

If you want to play with it without it going ballistic, hack the cgid
code that runs in the daemon so that when it reads the length of an
envvar it croaks if the length is unreasonable (e.g, > 1).  That's
where it always falls down for me, as I think you can see in the PR.

Re: Status of PR 29528? (Memory leaks in mod_cgid)

[Justin Erenkrantz]

--On August 26, 2005 1:49:01 PM -0400 Jeff Trawick <[EMAIL PROTECTED]> wrote:


Right.  If you must use mod_cgid on Solaris 10, go back to the next to
last Solaris Express driver prior to GA ;)  Recently I applied the
latest Solaris 10 updates and retested, without success.


Yup, my box has all the current updates too.


If you want to play with it without it going ballistic, hack the cgid
code that runs in the daemon so that when it reads the length of an
envvar it croaks if the length is unreasonable (e.g, > 1).  That's
where it always falls down for me, as I think you can see in the PR.


Okay, thanks for the pointer.

I may use this as an excuse to play with dtrace some as well.

And, at the least, if I can't fix it (i.e. it's an OS issue or something), I'm 
shipping this one over to the OpenSolaris folks and see if they have a clue. 
;-)  -- justin

Re: Status of PR 29528? (Memory leaks in mod_cgid)

[Jeff Trawick]

On 8/26/05, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
> --On August 26, 2005 1:49:01 PM -0400 Jeff Trawick <[EMAIL PROTECTED]> wrote:
> 
> > Right.  If you must use mod_cgid on Solaris 10, go back to the next to
> > last Solaris Express driver prior to GA ;)  Recently I applied the
> > latest Solaris 10 updates and retested, without success.
> 
> Yup, my box has all the current updates too.
> 
> > If you want to play with it without it going ballistic, hack the cgid
> > code that runs in the daemon so that when it reads the length of an
> > envvar it croaks if the length is unreasonable (e.g, > 1).  That's
> > where it always falls down for me, as I think you can see in the PR.
> 
> Okay, thanks for the pointer.
> 
> I may use this as an excuse to play with dtrace some as well.

That's what I thought ;)  The problem I found is that observing more
than one side of the socket makes it work.  But good luck to you!!!

Re: mod_include features request

[Graham Leggett]

Nick Kew wrote:

mod_include is a little less than thorough.  With xbithack, it'll check the 
page's last modification time to make it cacheable.  But it won't propagate

the checks to the included content.

A make-like scheme in mod_include would let it work better with mod_cache.


I've been planning to write a filter that adds an ETag to content (of a 
reasonablely manageable size), which will make all sorts of dynamic 
content cacheable.


This should help.

Regards,
Graham
--

Re: 2.1.7 Available for Testing & Voting

[Graham Leggett]

Paul Querna wrote:


Bundled with APR & APR-Util 1.2.1:
http://people.apache.org/~pquerna/dev/httpd-2.1.7/

Please test and vote on releasing 2.1.7 as beta.


I checked in a fix to the httpd.spec.in file to make httpd v2.1.7 build 
clean as an RPM: r240349.


Regards,
Graham
--

Re: Thoughts on Future Versions/Backporting

[Maxime Petazzoni]

Hi,

> This also means that most "new features" would wait for the "next
> stable" version to be released.  If the "next stable" isn't a 3 year
> cycle like 2.0->2.2, I believe this could be acceptable.
> 
> I believe that we should have more stable branches, more often.  I
> believe that we should try to only backport bugfixes and security issues
> to these branches, and attempt to avoid adding many new features.

+1.

I'm kinda new as an ASF committer, and all this backport stuff
surprised me a lot. I keep thinking we are spoiling our efforts on
backporting, backporting, again and again. Why can't we just move on ?
2.0 made is time, and everybody is looking forward for the 2.2 release
to show up.

Only minor fixes and security fixes should be backported. A new
version of a piece of code should be kept for the next release. That's
why we have releases, after all : to release new, better code :)

My 2 cents, too.
- Sam

-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.


signature.asc
Description: Digital signature

PATCH DisallowPost

[Russell Miller]

(I sent this once before but I think it was bounced, so if you get it twice, 
my apologies)

A patch has been submitted to mod_cgi.c that will allow the user to disallow 
post requests in affected directories.

History and reasoning, as well as a patch, is in the report, #36368.  I will 
duplicate that part here:

We wanted to disallow the POST method, because for our purposes we wanted the 
arguments to said calls to be logged in the access log.  We considered using 
LimitExcept, but upon trying it, I saw that a 403 error was returned, and a 
search of the bug database showed that you had no plans to fix this.  I don't 
understand your reasoning on that, but anyway.  We needed a 405 error, and the 
only other way to do it was to test it in the CGI code itself, which was ugly. 
 
So, in true open source style, I hacked on mod_cgi and made a patch.  This 
creates a new config directive called DisallowPost - it's an ACCESS_CONF 
directive.  It can be either On or Off.  If it's on and you try to access a 
location protected by it with POST, you'll get a 405 method not allowed, which 
is exactly the behavior we needed. 
 
The patch line numbers will be off because I also applied the patch that fixes 
the #exec cmd problem.  However, other than that, it should apply to stock 
2.0.54. 

--Russell

-- 

Russell Miller - [EMAIL PROTECTED] - Agoura Hills, CA

Re: Status of PR 29528? (Memory leaks in mod_cgid)

[Justin Erenkrantz]

--On August 26, 2005 1:58:05 PM -0400 Jeff Trawick <[EMAIL PROTECTED]> wrote:


I may use this as an excuse to play with dtrace some as well.


That's what I thought ;)  The problem I found is that observing more
than one side of the socket makes it work.  But good luck to you!!!


Works for me.  I can get it to happen with dtrace - not at all with truss 
though.  If it helps, my dtrace file is at:




Set it up such that we only have 1 worker thread (MaxClients 1, etc, etc.)...

Run it with:

./httpd.d  

When it blows up, you'll see the read return values being corrupt.  So, I'm 
fairly sure we're not doing something completely stupid.


I'm going to write this up and throw it at some of the OpenSolaris devs and 
see if they have any ideas.  -- justin

Re: Status of PR 29528? (Memory leaks in mod_cgid)

[Justin Erenkrantz]

--On August 26, 2005 3:00:13 PM -0700 Justin Erenkrantz 
<[EMAIL PROTECTED]> wrote:



I'm going to write this up and throw it at some of the OpenSolaris devs and
see if they have any ideas.  -- justin


Score one for the Solaris folks being around at 4pm on a Friday.  I've 
summarized the discussions so far in our PR (with pointers to their archives):




In short, yah, it's a Solaris bug.  Fixes are working their way through the 
pipeline.  They think we may be able to workaround this particular bug by 
avoiding the 'early' shutdown() call.


I'll try commenting out the shutdown() as well as trying out the current 
Solaris Express releases next week.  -- justin

[apreq2] problem with $req->args('key')

[Nikolay Ananiev]

$req->args('key'); doesn't return the value of 'key' but the whole query
string.

Re: [apreq2] problem with $req->args('key')

[Joe Schaefer]

"Nikolay Ananiev" <[EMAIL PROTECTED]> writes:

> $req->args('key'); doesn't return the value of 'key' but the whole
> query string.

Please use APR::Request::Apache2 instead of Apache2::Request.

-- 
Joe Schaefer