tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: JK2 module for AOLserver
Date Tue, 19 Nov 2002 18:27:51 GMT
Alexander Leyke wrote:


> "ajp13" worker factory seems to be hardcoded regardless of actual worker
> type. Here is a snippet from JTC-4.1.12/jk/native2/common/jk_workerEnv.c:

The reason is simple. 

There are 2 "interfaces": protocol and channel. In jk1, the JNI used its own 
protocol ( using String[], etc ). This creates 2 problems: 
- the jni code was harder to maintain
- it was actually slower - since most optimization went into the most used
code, and the Strings and all GC created big problems.

In jk2 we use ajp13 for all channels, including JNI. That allows us to reuse
the buffers and avoid object allocations from C - which improves a lot the 
performance of the code ( we also avoid a lot of expensive calls, etc ).
Same technique is also used (AFAIK) in mozilla bridge.



> I changed the code above to use "ajp13" or "worker.jni" depending on
> ch->mbean->localName , but that still didn't help, because
> jk2_jni_worker_service function in
> JTC-4.1.12/jk/native2/common/jk_worker_jni.c is a placeholder. I did
> make sure not to use default "lb" worker for JNI.

I'll check - worker_jni should be deprecated/removed, you should use 
the channel.

Also note that it is a good idea to use the 'lb' worker - even if you
use a single process, the overhead is very small and it will allow you to
add load balancing easier.



> Is JNI worker intentionally disabled, or am I misinterpreting the code?
> I could fix jk2_jni_worker_service function with some guidance, but is
> there a similar implementation gap in Tomcat 4 Java classes?

Yes, the jni worker shouldn't be used.


> 2) JTC build doesn't seem to be very friendly for non-GNU compilers. I
> use Sun Workshop, and had to write some hacks to make ant and libtool
> work with Sun's C compiler. In particular, both ant and libtool insisted
> on supplying invalid "-W" command option to compiler. I suspect that
> JTC-4.1.12/jk/jkant/java/org/apache/jk/ant/compilers/CcCompiler.java is
> intended for UCB cc support, and I need to write a separate class for
> ant to work with Sun's cc and bypass libtool (which configured itself
> mostly correctly to use Sun cc, but still insisted on "-W"). Had anyone
> had any relevant experience?

There is a target that allows use of ant-contrib's cpp tasks. 
IMHO we should deprecate jkant and switch to ant-contrib, at the moment 
they support far more compilers and seem to have an active community.

You can submit a patch to CcCompiler if you want, but I think it would be
better if you could help test ( and improve ) the cc tasks. ( AFAIK sun 
compiler is supported ).

Costin 




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message