Re: NIO Connector, please review
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: That's unfortunate. So regular is better? What are they doing with Grizzly? no, its me :) I need to come up with a non cpu sucking wait algorithm for the wait. once that is fixed, the performance should be close to identical For some reason, the performance went down further for me with that patch (although I noticed the CPU is being used properly this time, while before Tomcat was not using all the CPU available). that's strange, mine went up to the same level as the java.io connector, I'm not completely done with it though. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Filip Hanik - Dev Lists wrote: That's unfortunate. So regular is better? What are they doing with Grizzly? no, its me :) I need to come up with a non cpu sucking wait algorithm for the wait. once that is fixed, the performance should be close to identical For some reason, the performance went down further for me with that patch (although I noticed the CPU is being used properly this time, while before Tomcat was not using all the CPU available). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Jess Holle wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Alright, fixed, my last night checkin, the one I was unable to diff, caused the problem, I have reverted that one, and the Connector since we can use the fully qualified classname here. I am able to diff to see what got fixed, and it's trivial: all requests were processed as Comet events. yup, noticed that when I ran it in a debugger, I wanted to consolidate the two processSocket method into one, i did it wrong. I can confirm it now works. The two methods are fundamentally different, and one of them was actually named processSocketEvent until I changed it back to processSocket. However, the throughput is very bad at the moment (/usr/sbin/ab.exe -n 2 -c 10 -k http://127.0.0.1:8081/tomcat.gif): 800 req/s (with keepalive actually working) vs 6000+ for regular java.io. That's unfortunate. So regular is better? What are they doing with Grizzly? no, its me :) I need to come up with a non cpu sucking wait algorithm for the wait. once that is fixed, the performance should be close to identical Filip -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Alright, fixed, my last night checkin, the one I was unable to diff, caused the problem, I have reverted that one, and the Connector since we can use the fully qualified classname here. I am able to diff to see what got fixed, and it's trivial: all requests were processed as Comet events. yup, noticed that when I ran it in a debugger, I wanted to consolidate the two processSocket method into one, i did it wrong. I can confirm it now works. The two methods are fundamentally different, and one of them was actually named processSocketEvent until I changed it back to processSocket. However, the throughput is very bad at the moment (/usr/sbin/ab.exe -n 2 -c 10 -k http://127.0.0.1:8081/tomcat.gif): 800 req/s (with keepalive actually working) vs 6000+ for regular java.io. That's unfortunate. So regular is better? What are they doing with Grizzly? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
On 6/22/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: Filip Hanik - Dev Lists wrote: > Ok, I have a non SSL enabled Java NIO connector created and checked in. > It works in the exact way as APR, meaning it blocks on read and write, > So its no true NIO, but close enough to handle comet style traffic, and > to increase the connection count without increasing thread count. I really see no usefulness in such a connector (even if it did work). The one and only benefit is that you get to use the JVM native vendor network proprietary code rather than the ASF open source code. Really cool :) We also use JVM native code for java.lang, and in the old java.io connector :-) NIO code is open source as well - Classpath includes a decent implementation. The benefit is that nio, even if lower performance than APR, is part of the jre and so it's slightly easier to use. I think after the NIO connector is stable we should start deprecating the old java.io connector. Costin
Re: NIO Connector, please review
Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Alright, fixed, my last night checkin, the one I was unable to diff, caused the problem, I have reverted that one, and the Connector since we can use the fully qualified classname here. I am able to diff to see what got fixed, and it's trivial: all requests were processed as Comet events. yup, noticed that when I ran it in a debugger, I wanted to consolidate the two processSocket method into one, i did it wrong. I can confirm it now works. The two methods are fundamentally different, and one of them was actually named processSocketEvent until I changed it back to processSocket. However, the throughput is very bad at the moment (/usr/sbin/ab.exe -n 2 -c 10 -k http://127.0.0.1:8081/tomcat.gif): 800 req/s (with keepalive actually working) vs 6000+ for regular java.io. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Alright, fixed, my last night checkin, the one I was unable to diff, caused the problem, I have reverted that one, and the Connector since we can use the fully qualified classname here. I am able to diff to see what got fixed, and it's trivial: all requests were processed as Comet events. yup, noticed that when I ran it in a debugger, I wanted to consolidate the two processSocket method into one, i did it wrong. Filip -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Filip Hanik - Dev Lists wrote: Alright, fixed, my last night checkin, the one I was unable to diff, caused the problem, I have reverted that one, and the Connector since we can use the fully qualified classname here. I am able to diff to see what got fixed, and it's trivial: all requests were processed as Comet events. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: I did, just check http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2 In terms of negativity, not sure where your head is at, but there is none here. This was quite a subtle mention. The plan is that the socket will not get destroyed and deallocated before the error method of the servlet is called. If this is indeed done properly, then it is the application's fault and the Java code should not change. At the same time, I would like to get more robustness and add code for that in the native code, because in a very similar way, it is currently possible to crash Tomcat with APR using Java2D, which writes stuff asynchronously when finalizing its objects. yes, and I offered to help track these down and will do so. I quickly tested your NIO connector, and on Windows, it closes the connection after getting the first byte. I didn't have time to test further. Really, I ran through a large set of tests here and they all worked fine, both chunked encoding and content length based data. I am not able to get any requests served at all right now (as I said, using a telnet, the connection gets closed without an error being logged after getting the first byte), while the other connectors work fine. The configuration is: protocol="org.apache.coyote.http11.Http11NioProtocol" /> protocol="org.apache.coyote.http11.Http11Protocol" /> ok, lemme get on that one Alright, fixed, my last night checkin, the one I was unable to diff, caused the problem, I have reverted that one, and the Connector since we can use the fully qualified classname here. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: I did, just check http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2 In terms of negativity, not sure where your head is at, but there is none here. This was quite a subtle mention. The plan is that the socket will not get destroyed and deallocated before the error method of the servlet is called. If this is indeed done properly, then it is the application's fault and the Java code should not change. At the same time, I would like to get more robustness and add code for that in the native code, because in a very similar way, it is currently possible to crash Tomcat with APR using Java2D, which writes stuff asynchronously when finalizing its objects. yes, and I offered to help track these down and will do so. I quickly tested your NIO connector, and on Windows, it closes the connection after getting the first byte. I didn't have time to test further. Really, I ran through a large set of tests here and they all worked fine, both chunked encoding and content length based data. I am not able to get any requests served at all right now (as I said, using a telnet, the connection gets closed without an error being logged after getting the first byte), while the other connectors work fine. The configuration is: protocol="org.apache.coyote.http11.Http11NioProtocol" /> protocol="org.apache.coyote.http11.Http11Protocol" /> ok, lemme get on that one Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Filip Hanik - Dev Lists wrote: I did, just check http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2 In terms of negativity, not sure where your head is at, but there is none here. This was quite a subtle mention. The plan is that the socket will not get destroyed and deallocated before the error method of the servlet is called. If this is indeed done properly, then it is the application's fault and the Java code should not change. At the same time, I would like to get more robustness and add code for that in the native code, because in a very similar way, it is currently possible to crash Tomcat with APR using Java2D, which writes stuff asynchronously when finalizing its objects. I quickly tested your NIO connector, and on Windows, it closes the connection after getting the first byte. I didn't have time to test further. Really, I ran through a large set of tests here and they all worked fine, both chunked encoding and content length based data. I am not able to get any requests served at all right now (as I said, using a telnet, the connection gets closed without an error being logged after getting the first byte), while the other connectors work fine. The configuration is: protocol="org.apache.coyote.http11.Http11NioProtocol" /> protocol="org.apache.coyote.http11.Http11Protocol" /> Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: you gotta look at the glass as half full, not half empty :), it also doesn't crash the VM when the client aborts the connection on a comet request ;) I know of no crash problems. I think there's a very negative development atmosphere in the components you become involved with, I am not going to tolerate this for much longer. If you know of problems, and for example have debugged them, you should disclose them. I did, just check http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2 In terms of negativity, not sure where your head is at, but there is none here. I quickly tested your NIO connector, and on Windows, it closes the connection after getting the first byte. I didn't have time to test further. Really, I ran through a large set of tests here and they all worked fine, both chunked encoding and content length based data. Rémy Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Filip Hanik - Dev Lists wrote: you gotta look at the glass as half full, not half empty :), it also doesn't crash the VM when the client aborts the connection on a comet request ;) I know of no crash problems. I think there's a very negative development atmosphere in the components you become involved with, I am not going to tolerate this for much longer. If you know of problems, and for example have debugged them, you should disclose them. I quickly tested your NIO connector, and on Windows, it closes the connection after getting the first byte. I didn't have time to test further. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Ok, I have a non SSL enabled Java NIO connector created and checked in. It works in the exact way as APR, meaning it blocks on read and write, So its no true NIO, but close enough to handle comet style traffic, and to increase the connection count without increasing thread count. I really see no usefulness in such a connector (even if it did work). The one and only benefit is that you get to use the JVM native vendor network proprietary code rather than the ASF open source code. Really cool :) you gotta look at the glass as half full, not half empty :), it also doesn't crash the VM when the client aborts the connection on a comet request ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Filip Hanik - Dev Lists wrote: Ok, I have a non SSL enabled Java NIO connector created and checked in. It works in the exact way as APR, meaning it blocks on read and write, So its no true NIO, but close enough to handle comet style traffic, and to increase the connection count without increasing thread count. I really see no usefulness in such a connector (even if it did work). The one and only benefit is that you get to use the JVM native vendor network proprietary code rather than the ASF open source code. Really cool :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
Ok, I have a non SSL enabled Java NIO connector created and checked in. It works in the exact way as APR, meaning it blocks on read and write, So its no true NIO, but close enough to handle comet style traffic, and to increase the connection count without increasing thread count. Filip [EMAIL PROTECTED] wrote: let me fill in the other blanks, the connector will be modified so that it knows when it has enough data to proceed, ala, chunked encoding etc. that is still work to be done. but I wanted let you know how it conceptually could look similar to the APR connector, and how much of the code could be shared. Filip -Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 6:31 AM To: Tomcat Developers List Subject: NIO Connector, please review gents, I've worked on an NIO connector, since the NIO and APR model can be/are very similar, this is a fairly straightforward port. I'd like for you to review and then continue this as work, as this would allow me to have Comet support without the need for native libraries. After review, please suggest where I can continue the work, trunk or sandbox? If the attachments don't make it, here is a link http://www.halosg.com/connectors.zip This is not worked completed, but working, I wanna see if I can make optimizations, and of course, SSL support I don't see how this could possibly work. You are using non-blocking sockets, but you consider it to be an error if readSocket returns false (when all it actually means is that the data hasn't arrived yet :). The APR Connector doesn't have this problem since it uses blocking sockets (for much this reason). there is a discrepency, I need to fix the fill() method, for the other methods, false means, return the socket to the poller, free the thread and come back when you have more data. ala non blocking mode so there is some massaging to do, but they are not that different. And on writing, it does busy loop until it flushed it all out to the os buffer. Filip thanks Filip -- Filip Hanik 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NIO Connector, please review
let me fill in the other blanks, the connector will be modified so that it knows when it has enough data to proceed, ala, chunked encoding etc. that is still work to be done. but I wanted let you know how it conceptually could look similar to the APR connector, and how much of the code could be shared. Filip >> >> >>> -Original Message- >>> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] >>> Sent: Monday, June 19, 2006 6:31 AM >>> To: Tomcat Developers List >>> Subject: NIO Connector, please review >>> >>> gents, >>> I've worked on an NIO connector, since the NIO and APR model >>> can be/are >>> very similar, this is a fairly straightforward port. >>> I'd like for you to review and then continue this as work, as >>> this would >>> allow me to have Comet support without the need for native libraries. >>> After review, please suggest where I can continue the work, trunk or >>> sandbox? >>> >>> If the attachments don't make it, here is a link >>> http://www.halosg.com/connectors.zip >>> >>> This is not worked completed, but working, I wanna see if I can make >>> optimizations, and of course, SSL support >> >> I don't see how this could possibly work. You are using non-blocking >> sockets, but you consider it to be an error if readSocket returns false >> (when all it actually means is that the data hasn't arrived yet :). >> >> The APR Connector doesn't have this problem since it uses blocking >> sockets >> (for much this reason). > > there is a discrepency, I need to fix the fill() method, > for the other methods, false means, return the socket to the poller, free > the thread and come back when you have more data. ala non blocking mode > > so there is some massaging to do, but they are not that different. And on > writing, it does busy loop until it flushed it all out to the os buffer. > > > Filip > >> >>> >>> thanks >>> Filip >>> >>> -- >>> >>> >>> Filip Hanik >>> >> >> >> >> 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NIO Connector, please review
So it uses NIO to increase concurrency, ie, have more connections open than threads, same way as APR, but writing to the stream is not done non blocking, it still follows the request/response/1-thread model still lot of work to do Filip >> >> >>> -Original Message- >>> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] >>> Sent: Monday, June 19, 2006 6:31 AM >>> To: Tomcat Developers List >>> Subject: NIO Connector, please review >>> >>> gents, >>> I've worked on an NIO connector, since the NIO and APR model >>> can be/are >>> very similar, this is a fairly straightforward port. >>> I'd like for you to review and then continue this as work, as >>> this would >>> allow me to have Comet support without the need for native libraries. >>> After review, please suggest where I can continue the work, trunk or >>> sandbox? >>> >>> If the attachments don't make it, here is a link >>> http://www.halosg.com/connectors.zip >>> >>> This is not worked completed, but working, I wanna see if I can make >>> optimizations, and of course, SSL support >> >> I don't see how this could possibly work. You are using non-blocking >> sockets, but you consider it to be an error if readSocket returns false >> (when all it actually means is that the data hasn't arrived yet :). >> >> The APR Connector doesn't have this problem since it uses blocking >> sockets >> (for much this reason). > > there is a discrepency, I need to fix the fill() method, > for the other methods, false means, return the socket to the poller, free > the thread and come back when you have more data. ala non blocking mode > > so there is some massaging to do, but they are not that different. And on > writing, it does busy loop until it flushed it all out to the os buffer. > > > Filip > >> >>> >>> thanks >>> Filip >>> >>> -- >>> >>> >>> Filip Hanik >>> >> >> >> >> 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NIO Connector, please review
> > >> -Original Message- >> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] >> Sent: Monday, June 19, 2006 6:31 AM >> To: Tomcat Developers List >> Subject: NIO Connector, please review >> >> gents, >> I've worked on an NIO connector, since the NIO and APR model >> can be/are >> very similar, this is a fairly straightforward port. >> I'd like for you to review and then continue this as work, as >> this would >> allow me to have Comet support without the need for native libraries. >> After review, please suggest where I can continue the work, trunk or >> sandbox? >> >> If the attachments don't make it, here is a link >> http://www.halosg.com/connectors.zip >> >> This is not worked completed, but working, I wanna see if I can make >> optimizations, and of course, SSL support > > I don't see how this could possibly work. You are using non-blocking > sockets, but you consider it to be an error if readSocket returns false > (when all it actually means is that the data hasn't arrived yet :). > > The APR Connector doesn't have this problem since it uses blocking sockets > (for much this reason). there is a discrepency, I need to fix the fill() method, for the other methods, false means, return the socket to the poller, free the thread and come back when you have more data. ala non blocking mode so there is some massaging to do, but they are not that different. And on writing, it does busy loop until it flushed it all out to the os buffer. Filip > >> >> thanks >> Filip >> >> -- >> >> >> Filip Hanik >> > > > > 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: NIO Connector, please review
Costin Manolache wrote: On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote: I agree - it's good to have a single codebase ! But I strongly disagree that we should have one big bloated release that includes everything in the codebase. Look, all that I'm saying is that the code that is inside /tc6.0.x/trunk/ should always compile before any release, and that we do not 'componetisize' that code base. We can have as many builds with various parts from that code base as we wish, but not as an independent modules in a sense of being able to work with previous versions released. Anything else should IMHO go outside that tree, like jasper, commons, etc.. (as we do nowadays after all). If there is a need to make something completely independent of the core build, then this must not be the part of the core itself thought. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: > > Of course - all stuff must compile at least - but I don't think it's a > reasonable > requirement to have all modules or other things that are not part of tomcat > tested in order to do a release. > But in that case, they could not be the part of the Tomcat code. If you think that we can release the clustering independently of the Tomcat, then it's a separate project that only uses Tomcat, and it is not part of it. The same applies to any other 'module'. What do you mean ? Tomcat code ( i.e. whatever modules the tomcat pmc maintains ) can include multiple componets, as long as they are within the scope. Admin, cluster, etc are closely related with tomcat - I don't think you are arguing that they are not in the project scope. Tomcat code includes all the files in all svn repositories - and we can pick and chose what we release and how. Yes, the cluster/admin/etc can live on sourceforge or a separate apache project, but it's our choice if we want it in tomcat codebase, and how to release it. The thing I like with TC6 is that it treats its codebase as an entity. Having separate independent 'modules' makes it even worse compared with the current stuff we have. I agree - it's good to have a single codebase ! But I strongly disagree that we should have one big bloated release that includes everything in the codebase. We can discuss what exactly makes the Tomcat. If it's not the Clustering or Admin or what ever, then they'll need to be the separate projects that 'use Tomcat', and then and only then, we can version them separately. There is no requirement for a source file to be in a separate svn module or tree, or even separate project in order to have it's own separate release version and cycle. You can have files in the svn that are not included in the release, you can have files that are used in a different release, you can have multiple labels. There are many apache projects that release more than one thing, and code organization ( as svn repositories or source trees ) is orthogonal to release content and organization. ( and there is no rule that a release of cluster or admin must support only the last version of tomcat - but that's yet-another independent issue ) Costin
Re: NIO Connector, please review
I would love to backport it to Tc5.5 and that way also have Comet support in tc5.5.x Filip > +1 - I'm also working on a nio connector ( it is in sandbox ), but the > goals > are quite different, > I want to have it simpler and smaller than the apr model. I think > old-style > connector > should be deprecated, since JDK1.5 is now required there is no point in > having it. > > ( I assume this is intended for tomcat6 ? It could be backported to 5.x, > but > I'm not sure it's a good idea) > > Costin > > On 6/19/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: >> >> gents, >> I've worked on an NIO connector, since the NIO and APR model can be/are >> very similar, this is a fairly straightforward port. >> I'd like for you to review and then continue this as work, as this would >> allow me to have Comet support without the need for native libraries. >> After review, please suggest where I can continue the work, trunk or >> sandbox? >> >> If the attachments don't make it, here is a link >> http://www.halosg.com/connectors.zip >> >> This is not worked completed, but working, I wanna see if I can make >> optimizations, and of course, SSL support >> >> thanks >> Filip >> >> -- >> >> >> Filip Hanik >> >> >> - >> 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: NIO Connector, please review
Costin Manolache wrote: Of course - all stuff must compile at least - but I don't think it's a reasonable requirement to have all modules or other things that are not part of tomcat tested in order to do a release. But in that case, they could not be the part of the Tomcat code. If you think that we can release the clustering independently of the Tomcat, then it's a separate project that only uses Tomcat, and it is not part of it. The same applies to any other 'module'. The thing I like with TC6 is that it treats its codebase as an entity. Having separate independent 'modules' makes it even worse compared with the current stuff we have. We can discuss what exactly makes the Tomcat. If it's not the Clustering or Admin or what ever, then they'll need to be the separate projects that 'use Tomcat', and then and only then, we can version them separately. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: > > I don't see the benefit of having things like cluster support in the tomcat > release - > if someone does want a cluster, they can easily download an additional > jar - > setting > up a cluster involves a lot of work, we won't make it much simpler by > bundling the jar with > tomcat. > Well, I agree with you. We can have a build like: ant core, ant clustering, etc... No problem with that. What I'm saying is that if the clustering is broken, we should not have an release. First of all the release requires a SVN tag, and just imagine if someone wishes to create a build for some tagged release, and some 'module' is broken. It's simply confusing. The tomcat release has a SVN tag - and the release includes all the tomcat files. Cluster and other modules can be broken - and can be released later, with their own SVN release tags. Of course - all stuff must compile at least - but I don't think it's a reasonable requirement to have all modules or other things that are not part of tomcat tested in order to do a release. Costin
Re: NIO Connector, please review
Costin Manolache wrote: I don't see the benefit of having things like cluster support in the tomcat release - if someone does want a cluster, they can easily download an additional jar - setting up a cluster involves a lot of work, we won't make it much simpler by bundling the jar with tomcat. Well, I agree with you. We can have a build like: ant core, ant clustering, etc... No problem with that. What I'm saying is that if the clustering is broken, we should not have an release. First of all the release requires a SVN tag, and just imagine if someone wishes to create a build for some tagged release, and some 'module' is broken. It's simply confusing. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: > > By modules/ I mean mostly release units - so maybe a build.xml to create > build and package the module, some readme, manifest, etc. Tomcat normal > release wouldn't include the module, but it can be released independently, > maybe > for multiple versions of tomcat. > Look, if someone is willing to break the build it will do it no mater what. Like said, having multiple builds is fine with me, but having multiple builds just for the sake of some broken module is not. If the module is part of the Tomcat, then there can be no release if its build fails. It is just the same as for the Httpd etc. This is not an issue of 'broken build', it's an issue of release units and lifecycle. A module release cycle should not block the release of tomcat - it's just an optional add-on that has it's own life and version number. Also, I see no purpose of backporting the modules separately to the previous versions. If we have a product, then we can either provide the patch to the previous version as a whole, or simply say to the people to use the current stable version. If the patch will only relate to the module A, then it will be treated as a patch to the Tomcat6.x.y no to the module A for the Tomcat6.x.y. IMHO that'll be less confusing to the end users. Ok. That's a separate issue as well, sorry for mixing it up. What I would like is for tomcat6 release to not include all possible features. Maybe for backward compatibility we need to include all that tomcat5 includes, maybe we can move out some large ones or things that are still refactored ( like cluster support ). I don't see the benefit of having things like cluster support in the tomcat release - if someone does want a cluster, they can easily download an additional jar - setting up a cluster involves a lot of work, we won't make it much simpler by bundling the jar with tomcat. Costin
Re: NIO Connector, please review
Costin Manolache wrote: By modules/ I mean mostly release units - so maybe a build.xml to create build and package the module, some readme, manifest, etc. Tomcat normal release wouldn't include the module, but it can be released independently, maybe for multiple versions of tomcat. Look, if someone is willing to break the build it will do it no mater what. Like said, having multiple builds is fine with me, but having multiple builds just for the sake of some broken module is not. If the module is part of the Tomcat, then there can be no release if its build fails. It is just the same as for the Httpd etc. Also, I see no purpose of backporting the modules separately to the previous versions. If we have a product, then we can either provide the patch to the previous version as a whole, or simply say to the people to use the current stable version. If the patch will only relate to the module A, then it will be treated as a patch to the Tomcat6.x.y no to the module A for the Tomcat6.x.y. IMHO that'll be less confusing to the end users. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: > Maybe create a modules/ under tomcat6 - with the definition 'stuff that can > be > released independently, and may support older versions of tomcat as well' > Or just 'can be released independently'. > Hmm, I'm not very much in favor of that. If the 'module' is mature enough it commit frequency will be much lower then the rest of the project, and thats it. IMHO TC6 should be maintained as an entity. We can have multiple builds of course; light, medium, full, etc.. but the code should be once and for all in the common tree. It would require more responsibility from all the commiters, not to break other commiters code, but at the and of the day we should be OK with that. I wasn't talking about code location - java code can still be in the java/ directory, and should at least compile ( or be excluded in the javac statement ). By modules/ I mean mostly release units - so maybe a build.xml to create build and package the module, some readme, manifest, etc. Tomcat normal release wouldn't include the module, but it can be released independently, maybe for multiple versions of tomcat. Costin
RE: NIO Connector, please review
> -Original Message- > From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] > Sent: Monday, June 19, 2006 6:31 AM > To: Tomcat Developers List > Subject: NIO Connector, please review > > gents, > I've worked on an NIO connector, since the NIO and APR model > can be/are > very similar, this is a fairly straightforward port. > I'd like for you to review and then continue this as work, as > this would > allow me to have Comet support without the need for native libraries. > After review, please suggest where I can continue the work, trunk or > sandbox? > > If the attachments don't make it, here is a link > http://www.halosg.com/connectors.zip > > This is not worked completed, but working, I wanna see if I can make > optimizations, and of course, SSL support I don't see how this could possibly work. You are using non-blocking sockets, but you consider it to be an error if readSocket returns false (when all it actually means is that the data hasn't arrived yet :). The APR Connector doesn't have this problem since it uses blocking sockets (for much this reason). > > thanks > Filip > > -- > > > Filip Hanik > 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: NIO Connector, please review
Costin Manolache wrote: Maybe create a modules/ under tomcat6 - with the definition 'stuff that can be released independently, and may support older versions of tomcat as well' Or just 'can be released independently'. Hmm, I'm not very much in favor of that. If the 'module' is mature enough it commit frequency will be much lower then the rest of the project, and thats it. IMHO TC6 should be maintained as an entity. We can have multiple builds of course; light, medium, full, etc.. but the code should be once and for all in the common tree. It would require more responsibility from all the commiters, not to break other commiters code, but at the and of the day we should be OK with that. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: > > What about finally creating tomcat-modules or tomcat-addons ( or any other > name ), > for stuff that is (more or less) tomcat version independent, or at least > works for > multiple recent versions, and can be released independently ? > > This way the cluster stuff would have a better home too. > Agreed, but that would probably lead to the same thing we already have, multiple connectors, etc.. I think we can make some effort and better integrate the stuff, without going again to separation that would end up with confusing versions. The thing I like with TC6.X is that its entire functionality is integrated for the fist time. Yes - that's why I jumped when I heard about having some stuff in j-t-c :-) ( the native code is still there actually, but I see an empty native in tc6 ) Maybe create a modules/ under tomcat6 - with the definition 'stuff that can be released independently, and may support older versions of tomcat as well' Or just 'can be released independently'. ( the code can still be in java/ - or under modules, it doesn't matter as long as the actual realease of tomcat doesn't include it, and a separate release of the module can be made ) BTW - how is mod_ajp_proxy doing ? Costin
Re: NIO Connector, please review
Costin Manolache wrote: What about finally creating tomcat-modules or tomcat-addons ( or any other name ), for stuff that is (more or less) tomcat version independent, or at least works for multiple recent versions, and can be released independently ? This way the cluster stuff would have a better home too. Agreed, but that would probably lead to the same thing we already have, multiple connectors, etc.. I think we can make some effort and better integrate the stuff, without going again to separation that would end up with confusing versions. The thing I like with TC6.X is that its entire functionality is integrated for the fist time. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: > are quite different, > I want to have it simpler and smaller than the apr model. I think old-style > connector > should be deprecated, since JDK1.5 is now required there is no point in > having it. > Sorry for stealing the thread ;) What about old jk2 connectors found again in the tc6.x branch. I would hate to have multiple AJP flavors once again (except the transport layer dependent: JIO, NIO, APR) I think jk2 was deprecated ( at least the native part ), and anything specific to the native2 should be removed. Can we once and for all remove those obsolete stuff or make some merge if something is missing? +1 The mod_jk config generation stuff should not be the part of tc6.x branch (eventually a separate thing under tomcat-connectors), so that we have a single http core, ajp core, and stuff that is transport layer dependent. I would not be in favor to see multiple http protocol parsers, etc. It would only make the assurance for the RFC harder. +1 - but now tomcat-connectors is a bit confusing in context of tomcat6, where the java code is branched. What about finally creating tomcat-modules or tomcat-addons ( or any other name ), for stuff that is (more or less) tomcat version independent, or at least works for multiple recent versions, and can be released independently ? This way the cluster stuff would have a better home too. Costin
Re: NIO Connector, please review
Costin Manolache wrote: are quite different, I want to have it simpler and smaller than the apr model. I think old-style connector should be deprecated, since JDK1.5 is now required there is no point in having it. Sorry for stealing the thread ;) What about old jk2 connectors found again in the tc6.x branch. I would hate to have multiple AJP flavors once again (except the transport layer dependent: JIO, NIO, APR) Can we once and for all remove those obsolete stuff or make some merge if something is missing? The mod_jk config generation stuff should not be the part of tc6.x branch (eventually a separate thing under tomcat-connectors), so that we have a single http core, ajp core, and stuff that is transport layer dependent. I would not be in favor to see multiple http protocol parsers, etc. It would only make the assurance for the RFC harder. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NIO Connector, please review
+1 - I'm also working on a nio connector ( it is in sandbox ), but the goals are quite different, I want to have it simpler and smaller than the apr model. I think old-style connector should be deprecated, since JDK1.5 is now required there is no point in having it. ( I assume this is intended for tomcat6 ? It could be backported to 5.x, but I'm not sure it's a good idea) Costin On 6/19/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: gents, I've worked on an NIO connector, since the NIO and APR model can be/are very similar, this is a fairly straightforward port. I'd like for you to review and then continue this as work, as this would allow me to have Comet support without the need for native libraries. After review, please suggest where I can continue the work, trunk or sandbox? If the attachments don't make it, here is a link http://www.halosg.com/connectors.zip This is not worked completed, but working, I wanna see if I can make optimizations, and of course, SSL support thanks Filip -- Filip Hanik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
