Re: AJP using APR

2005-06-16 Thread Remy Maucherat

Bill Barker wrote:
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 ;-).


From what I can tell, it works well enough, so I'm doing ok ;) I assume 
it could be faster with a native friendly behavior at the VM level, of 
course.


Now that it doesn't just crash, I'll add AJP on APR to the build, and do 
the same enable-if-APR-is-present as with HTTP. Performance seems 
relatively decent (compared to regular AJP). I'll see if I can 
eventually improve things by using direct buffers.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP using APR [T20050613001A]

2005-06-12 Thread business
Dear tomcat-dev@jakarta.apache.org,

Thanks for writing to Webshots!

We received your message on 6/12/2005.
Your tracking number for this message is : T20050613001A

** IMPORTANT: PLEASE DO NOT REPLY TO THIS EMAIL! **

This is an automatic response to let you know that your Webshots Corporate 
email will be personally answered as soon as possible, usually within 3 
business days.

Our customer support staff is available to respond to messages during regular 
business hours, excluding holidays.

Thanks again for your questions and comments,

The Webshots Support Team


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP using APR

2005-06-12 Thread Bill Barker


- Original Message - 
From: "Costin Manolache" <[EMAIL PROTECTED]>

To: 
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]



Re: AJP using APR

2005-06-12 Thread Costin Manolache

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.



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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP using APR

2005-06-10 Thread Bill Barker

"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 ;-).

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




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP using APR

2005-06-10 Thread Costin Manolache

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.



But where is the code ?

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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP using APR

2005-06-09 Thread Remy Maucherat

Bill Barker wrote:
So, where is it already?  Some of use want to see how you can beat 
Costin ;-).


Right now, I'm not planning on beating anyone, it's just my crap work 
code (which doesn't actually work yet). I haven't benched anything, and 
my experience with AJP is very limited.


I used the package org.apache.coyote.ajp for it, and it reuses most of 
the message code, parsing and composition from regular AJP. One of the 
issues I'm facing, however, is that the usage of JNI will make the 
current code subpar, where it would be a lot better to do message 
reading and writing (this means composition of the messages to avoid 
useless bytes copying) using direct buffers. So there's a lot of work 
left, and it will remain experimental for a little while.


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).


Well, yes, I'll have to use a direct ByteBuffer like I do for HTTP. 
Otherwise, byte array copy over JNI will be slower. It's quite annoying, 
but using JNI imposes a certain design for buffering :(


One of the possibilities is to have AjpMessage (I renamed it, sorry) 
backed by a direct BB, or - as I am investigating at the moment - just 
write directly to a large BB. Reading, which faces the same problem, 
will likely have to use a large direct BB to avoid useless copying. For 
example, the current AJP code does two reads to read a message. Since in 
JNI, the best optimization is to lower the amount of JNI calls, this 
will have to be changed (which has fairly large consequences).


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AJP using APR

2005-06-08 Thread Bill Barker


- Original Message - 
From: "Remy Maucherat" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Sent: Tuesday, June 07, 2005 8:42 AM
Subject: AJP using APR



Hi,

I'd like to add my WIP code for AJP based on APR. It's not done yet, but it 
would be convinient to have the code there, just in case. It won't be 
compiled in or used (even if APR is available) for now, to avoid possible 
problems.




So, where is it already?  Some of use want to see how you can beat Costin 
;-).


I used the package org.apache.coyote.ajp for it, and it reuses most of the 
message code, parsing and composition from regular AJP. One of the issues 
I'm facing, however, is that the usage of JNI will make the current code 
subpar, where it would be a lot better to do message reading and writing 
(this means composition of the messages to avoid useless bytes copying) 
using direct buffers. So there's a lot of work left, and it will remain 
experimental for a little while.




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).



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

AJP using APR

2005-06-07 Thread Remy Maucherat

Hi,

I'd like to add my WIP code for AJP based on APR. It's not done yet, but 
it would be convinient to have the code there, just in case. It won't be 
compiled in or used (even if APR is available) for now, to avoid 
possible problems.


I used the package org.apache.coyote.ajp for it, and it reuses most of 
the message code, parsing and composition from regular AJP. One of the 
issues I'm facing, however, is that the usage of JNI will make the 
current code subpar, where it would be a lot better to do message 
reading and writing (this means composition of the messages to avoid 
useless bytes copying) using direct buffers. So there's a lot of work 
left, and it will remain experimental for a little while.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]