|
re-sending :
Am I missing details?
Calling ap_rflush() at the end of ws_write() in mod_jk.c is causing me
problems when doing downloads from the server to a client.
Performance degradation and, less importantly, memory usage, are the problems.
During calls to ap_rwrite() in ws_write, a brigade is created and
used to move data. When done, a call to apr_brigade_destroy()
is made. A call to apr_pool_cleanup_kill() ensures that the registered
cleanup entry is removed from the cleanups linked list associated
with the request pool. The brigade is then cleaned up.
After that, a call is done to ap_rflush() within ws_write to do what seems to me
the same operations that were just made. ap_rflush is also creating a brigade
on every call and adds its cleanup function to the cleanups list.
The brigades created by ap_rflush will not be destroyed before the
request is finished, if I understand correctly.
ap_rflush job is to destroy the brigade created by the ap_rwrite
operation, which was already done and removed from the cleanups
list previously. In my test, at the beginning of a download, mod_jk is doing
about 250 calls to ap_rflush() every seconds. This is when the cleanups list
is of reasonable size, gets much slower quickly because of the time spent
scanning the cleanups list.
I am downloading large files (> 1GB), it takes time and
by the time I get to the end of the download, my cleanups list has grow
to over 200000 members and it has to be scanned unsuccessfully from beginning to
end in search of a brigade that was previously removed.
Removing the call to ap_rflush() is working great for me:
I ran stress and functional testing on my server w/ no apparent problems.
My question are:
Why is ws_write() calling ap_rflush()? I am sure other users are suffering from it.
Could it be just removed?
If it is essential, any suggestions for a workaround for my problem?
This is a link to a bug that is related to the extra brigade created by
ap_rflush():
Thank you very much,
Jean-Jacques >>> [EMAIL PROTECTED] 5/16/2005 1:57 AM >>> Hi,
JK 1.2.13 has been taggeded as we agreed last week, and the tarballs are available at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.13/ For those that don't have WIN32 compiler there is a set of binaries at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/ Please test as much as possible since we'll be aiming towards 1.2.14 stable by simply rettaging if no bugs are present. In case they are, we can made few 1.2.14-rc-xx versions, as we done with 1.2.7. Further more, as agreed, we'll froze the 1.2 branch and only do a bug fixing, so please don't add any new features to that branch. Regards, Mladen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |
Index: jk/native/apache-2.0/mod_jk.c
===================================================================
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.143
diff -u -r1.143 mod_jk.c
--- jk/native/apache-2.0/mod_jk.c 7 May 2005 08:15:47 -0000 1.143
+++ jk/native/apache-2.0/mod_jk.c 12 May 2005 21:07:16 -0000
@@ -388,17 +388,6 @@
}
- /*
- * To allow server push. After writing full buffers
- */
-#ifndef AS400
- if (ap_rflush(p->r) != APR_SUCCESS) {
- ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_CRIT, 0,
- NULL, "mod_jk: Error flushing");
- return JK_FALSE;
- }
-#endif
-
}
return JK_TRUE;--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
