Alexander Leyke wrote: > Costin Manolache wrote: > >>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. >> >> >> > Do you mean "ajp13" channel would work with in-process worker?
Ajp13 protocol ( marshalling, etc ) is used for in-process communication and out of process communication. By marshalling the data we avoid some expensive and complex JNI operations, and benefit of all optimizations done on java side ( and the code is simpler ). The worker_jni code is just used to start tomcat in-process, but not for request forwarding. The JNI channel is special because it is single-threaded ( a doors channel will use the same type of code ), and that has some implications in how the request is processed - but the data encoding is the same. > Let me rephrase my initial question. I am interested in Tomcat executing > in-process. If JNI worker cannot be used, what alternative do I have to > run Tomcat in-process? Is JNI worker permanently out or will be > re-enabled in the future (what's the timetable?) The JNI worker is working for IIS and Apache2, I see no reason why it won't work with AOLserver. ( I suppose you're aware of the jk1 AOLserver connector - it also used JNI, so you shouldn't have any major problems ) Just get the socket to work ( it's easier to debug the server-specific code), then enable the jni channel and worker. > In case I am out-of luck with in-process Tomcat <g>, what is the highest > performance alternative for a Web server to talk to Tomcat 4? You could use unix channel. Or ( if on solaris ) implement a doors channel ( most of the tricks for making it work are already done for JNI - i.e. single threaded communication ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
