On 08/24/2010 04:56 PM, jean-frederic clere wrote:
On 08/24/2010 04:30 PM, Mladen Turk wrote:
On 08/24/2010 04:07 PM, jean-frederic clere wrote:
On 08/24/2010 03:33 PM, mt...@apache.org wrote:
Author: mturk
Date: Tue Aug 24 13:33:18 2010
New Revision: 988537
URL: http://svn.apache.org/viewvc?rev=988537&view=rev
Log:
Allow using vedor APR that have lower then required version but
required API
Modified:
tomcat/native/trunk/native/build/tcnative.m4
tomcat/native/trunk/native/src/jnilib.c
Modified: tomcat/native/trunk/native/build/tcnative.m4
URL:
http://svn.apache.org/viewvc/tomcat/native/trunk/native/build/tcnative.m4?rev=988537&r1=988536&r2=988537&view=diff
==============================================================================
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Tue Aug 24 13:33:18
2010
@@ -33,8 +33,11 @@ AC_DEFUN(TCN_FIND_APR,[
sapr_version="`echo $sapr_pversion|sed -e 's/\([a-z]*\)$/.\1/'`"
tc_save_IFS=$IFS; IFS=.; set $sapr_version; IFS=$tc_save_IFS
decimal_apr_version=`printf %02d%02d%03d ${1} ${2} ${3}`
- if test "${decimal_apr_version}" -lt "0104002"; then
- AC_MSG_ERROR(Found APR $sapr_version. You need version 1.4.2 or
newer installed.)
+ if test "${decimal_apr_version}" -lt "0102000"; then
+ AC_MSG_ERROR(Found APR $sapr_version. You need version 1.2 or
newer installed.)
+ fi
+ if test "${decimal_apr_version}" -lt "0104000"; then
+ AC_MSG_NOTICE(APR $sapr_version detected.)
fi
APR_BUILD_DIR="`$apr_config --installbuilddir`"
Modified: tomcat/native/trunk/native/src/jnilib.c
URL:
http://svn.apache.org/viewvc/tomcat/native/trunk/native/src/jnilib.c?rev=988537&r1=988536&r2=988537&view=diff
==============================================================================
--- tomcat/native/trunk/native/src/jnilib.c (original)
+++ tomcat/native/trunk/native/src/jnilib.c Tue Aug 24 13:33:18 2010
@@ -65,9 +65,16 @@ JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM
apr_version(&apv);
apvn = apv.major * 1000 + apv.minor * 100 + apv.patch;
if (apvn< 1400) {
+#if defined(HAVE_POOL_PRE_CLEANUP)&& defined(HAVE_POLLSET_WAKEUP)
But apr_pollset_wakeup() is not used even in trunk, so why?
Work in progress ...
Will be used in new Poll.interrupt API so we can remove all
that clumsy pollTime/maintainTime logic for adding new sockets
to the pollset.
It should lower the accept latency, remove the need for
socket add queue and remove unnecessary thread context switches.
Well the accept is done in a different thread anyway. Additionally with
defer accept we won't see any changes accept latency.
Right, I didn't mean accept since we never put freshly
accepted sockets in the poll anyhow.
I meant adding accepted sockets for the first time after
the request was handled and marked for keepalive.
Currently we do a probe read cause the pollTime latency is
too high for directly using the pollset.
Also once when added to the queue the pollTime determines the
new request latency cause during the time when we add the
socket to the pollset we are presuming no new data will
arrive during the pollTime.
Whether this operation
socket->nonblock, read, socket->block, add to poll queue
is slower or faster then a apr_pollset_wakeup call is
IMO worth experimenting.
If it proves to have none or very low impact we just won't
use it.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
