----- Original Message -----
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <tomcat-dev@jakarta.apache.org>
Sent: Sunday, June 12, 2005 5:31 PM
Subject: Re: AJP using APR
Bill Barker wrote:
"Costin Manolache" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Bill Barker wrote:
If I understand you correctly, you want MsgAjp to use ByteBuffer instead
of byte []. At the cost of never supporting JDK 1.3 ever again, this
would probably actually improve the performance of ChannelSocket (after
changing it to use a blocking SocketChannel).
The biggest difference will be if it's a 'direct' buffer, i.e. zero copy.
Classpath ( gcj, kaffe, etc ) also has byte buffer support - so it should
be ok, if anyone needs jdk1.3, they can use the old code.
Yes, the idea was that it would be a direct buffer.
But where is the code ?
It's on my hard-drive. Unlike Remy's APR stuff, o.a.jk is supposed to be
a pretty stable package(s) at this point. I can't just check in stuff
like this without a lot of testing to make sure that it doesn't break
anything more than JDK 1.3 compatibility ;-).
That's why C has conditional compilation - and java has some
options-controlled ugly 'if' code :-) It doesn't break anything if the
option/def is not selected ( just makes the code a bit uglier ). This way
even JDK1.3 will be happy.
Yeah, well, I hate ugly ;-). Using NIO will be switchable (and off by
default for BC for now). Mark says he doesn't want to use j-t-c HEAD for
4.1.x, and if there is ever another 3.3 release, I'll just add a comment
that using the Coyote-JK connector requires JDK 1.4 (similar to the one for
the HTTP/1.1 connector). The old AJP connector works well enough in 3.3.
I've been spending the weekend fighting with APR-1, that doesn't want to use
the OpenSSL .a files. At this point, I'm probably just going to admit
defeat. It's a test box, so I can simply install a test-version of the
OpenSSL .so files and link against that. It's sad that the libtool from
httpd-2.0.50 works fine with the .a files :(, but APR-1 doesn't.
The biggest problem in JNI ( and probably - in Java playing nice with other
languages and the rest of the platform ) is the objects and buffers moving
around almost randomly. Yes, it may improve a bit the garbage collection
speed - so people can create millions of garbage objects without thinking
about it, unlike most other languages that require you to think when
allocating objects - but it is the kind of optimization that has disastrous
consequences on the rest of the systems. Luckily gcj and kaffe and mono
don't do this crazy thing.
Direct buffers is one band-aid that should be used whenever possible.
Fortunately, this is Remy's problem ;-).
Costin
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication
in error, please notify us immediately by e-mail and then delete all copies of
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through
the Internet is not secure. Do not send confidential or sensitive information,
such as social security numbers, account numbers, personal identification
numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
