I think I'll be -0 on this.
There are 2 main reasons:
1. There are not too many people who work on the JNI - it's tricky
and not very easy, and for this reason we had quite a few improvements
in jk1. The performance of the old jni worker were pretty poor,
with many of the optimizations done in the socket workers ( like
char-byte conversions, recycling of buffers ) not used in jni.
Using the same path for jni solved this problem - and having a 4 byte
overhead and a redundant length is not ( IMHO ) such a big price.
2. I would like to get a release - I'm getting a bit uncomfortable with
long release cycles, there are many things that will improve with jk2
( including IMHO the maintainance of the code ).
Post jk2.0, I'm +1 - but I think the real problem is in a different
place. We do quite few tricks to deal with the single-thread model,
it is not very intuitive or clear.
Most people are familiar and understand the 2 thread model ( blocking
sender and receiver ), even with our twists for one-way messages.
Besides, I'm pretty convinced that the next Msg should be a standard-based
one, with whatever header is needed. I think treating JNI as a regular
channel is very powerfull, even if that means some redundancy.
( if you feel strongly this change is needed, I won't -1 it ).
Costin
On Sat, 15 Jun 2002, Mladen Turk wrote:
> Hi,
>
> I would like to clean some things in native2, so here is something
> (concept probably) that's itching me.
>
> First of all can we agree that we have a well defined communication
> environment between the connector and the web server?
> I think we can, cause there are no third party stuff intervening in our
> communication channel.
>
> So my question is what would be the 'real' purpose of the following for
> example:
>
> public void end() {
> len=pos;
> int dLen=len-4;
>
> buf[0] = (byte)0x41;
> buf[1] = (byte)0x42;
> buf[2]= (byte)((dLen>>>8 ) & 0xFF );
> buf[3] = (byte)(dLen & 0xFF);
> }
>
> This is probably ok for the socket channels, but for the jni (shmem
> perhaps) that is simply not needed and is waste of cpu cycles.
>
> For example inside the JniHandler we are calling:
> (the raw is always 0, from ChannelJni)
>
> int status=apr.jkInvoke( xEnv,
> nativeJkHandlerP,
> nativeContext,
> code, msg.getBuffer(), 0, msg.getLen(),
> raw );
>
> And inside the C part of AprImpl_jkInvoke
>
> if( raw == 0 ) {
> rc=ep->reply->checkHeader( env, ep->reply, ep );
> } else {
> ep->reply->len = len;
> ep->reply->pos= off;
> }
>
> So we are checking the message length of the direct call with the
> already defined length (by the call itself).
>
> The purpose of this entire tirade is that I would like to write the
> another MsgAjp for the jni only, that would also give me the needed java
> module abstractions.
>
> If I get some +1 for that I'll dig into it (as soon as I receive my
> account password).
>
> MT.
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
