Re: AJP using APR
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]
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
- 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
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
"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
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
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
- 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
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]
