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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
