httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37100] - SEGV in mod_proxy_ajp
Date Mon, 17 Oct 2005 15:27:02 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37100>.
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=37100


rpluem@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16709|0                           |1
        is obsolete|                            |




------- Additional Comments From rpluem@apache.org  2005-10-17 17:26 -------
Created an attachment (id=16722)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16722&action=view)
Patch against trunk

Thanks for the report, the patches and especially the testcase. The problem
turned out to be more complicated, so your patch does not resolve it
completely. Because the initial idea had been to capture all data sent by
Tomcat in the output_brigade first and sent it up the filter stack in one blow
afterwards, for every new AJP message that arrives a new ajp_msg_t structure
(including an 8k buffer) will be created on the heap. Thus the apache process
continues to consume memory even if we call ap_pass_brigade and
apr_brigade_cleanup in the meantime as this data will only be freed at the end
of the client connection. I adjusted the code such that the ajp_msg_t structure
will be reused to fix this. Furthermore I pass the brigade to the filter stack
after *each* CMD_AJP13_SEND_BODY_CHUNK without any buffering. Even more I add a
flush bucket to the brigade each time to ensure that the data gets written to
the network. Reasons:
Buffering should be done inside Tomcat and usually it is done within. There may
be situations where the developer of a jsp / servlet intentionally flushes the
outputstream (e.g. tunneling another protocol over http, doing streaming). As I
have no information about this in the AJP message I assume that every AJP
message should be written immediately to the client. Of course this degrades
performance. There is also a bad sideeffect on standard jsps. As the default
buffer for jsps is 8k, but AJP13_MAX_SEND_BODY_SZ is 8 bytes smaller, a buffer
flushing of a jsp typically arrives in two AJP messages with data sizes of 8184
and 8 byte. So the 8 bytes of the second message get sent separately over the
wire. Thoughts should be done later how to optimize this.

Please check and test the attached patch. You may face difficulties applying
the patch as I did some style cleanup operations on mod_proxy_ajp.c before. So
it may be wise if you apply the following patch before this one:
http://svn.apache.org/viewcvs.cgi/httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c?rev=325879&r1=232247&r2=325879

-- 
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message