tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: AJP using APR
Date Mon, 13 Jun 2005 00:31:23 GMT
Bill Barker wrote:
> "Costin Manolache" <cmanolache@yahoo.com> wrote in message 
> news:d8cmic$vvk$1@sea.gmane.org...
> 
>>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.


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.

Costin


> 
> 
>>Costin
>>
>>
>>
>>
>>>>Rémy
>>>
>>>
>>>
>>>
>>>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: tomcat-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org 


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


Mime
View raw message