You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2005/11/19 11:25:19 UTC
[VOTE] APR or NIO ? (was:Re: Any other functionality missing from
Tomcat 5.5.12 that relies on JSDK 5.0?)
Costin Manolache wrote:
> NIO is used AFAIK by Jetty and Resin, and probably others. And it's
> the 'standard'
> solution for select-like operations ( even if the standard is as usual
> not the best solution ).
Selects and stuff like that is the reason why I will vote against NIO,
so I find all this quite ironic.
This stuff are implementation details: we do not need to use a
"standard" if it doesn't make sense, since it is not exposed to users.
> Well, most java APIs - including the servlet - are over engineered.
> And most are
> far from perfect solution ( again, servlet is a good example :-). Yes,
> I also hate
> the way buffers flip and you can't know where is the data ( before or
> after position ),
> most of the channel and select are more complex than the APR equivalent.
>
> But NIO is a valid solution - with 1.6 I'm pretty sure the performance
> will be comparable
> ( with poll, etc ). APR is not the only valid solution ( and on top of
> that - the way we
> implement the connector on top of APR is far from either simple or right ).
I think we need to organize a community vote then, so that I do not
waste my time.
So here we go:
<ballot>
I think the IO design for connectors used by Tomcat should be:
[ ] NIO selectors, etc (this means 100% NIO)
[ ] APR (this means 50% NIO, where NIO is only used for all the objects
exposed at the higher level)
</ballot>
Obviously, I vote APR.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)
Posted by Costin Manolache <co...@gmail.com>.
On 11/19/05, Yoav Shapira <yo...@apache.org> wrote:
> On a related note, we can add a server-highperformance.xml configuration file
> that ships with Tomcat, and uses APR and whatever else we can think of to
> increase perfdormance out of the box. This is similar to the multiple
> httpd-XXX.conf files that ship with the HTTP web server.
That brings up another issue - you only have to have the .so file in
your path and the
current httpd.conf will pick it up and magically use APR. Having a
clear option 'use apr'
or a clear apr connector is IMO a cleaner solution, and can avoid some
headaches ( I had
problems with debugging inside eclipse when the .so was loaded, etc )
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)
Posted by Costin Manolache <co...@gmail.com>.
On 11/19/05, Remy Maucherat <re...@apache.org> wrote:
> <ballot>
> I think the IO design for connectors used by Tomcat should be:
> [X] NIO selectors, etc (this means 100% NIO)
> [X] APR (this means 50% NIO, where NIO is only used for all the objects
> exposed at the higher level)
> </ballot>
Obviously, I vote both - plus the classical style. There is no reason
to have only one,
just like we support multiple SSL implementations and multiple realms
- we can support
multiple techniques to do IO.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)
Posted by Henri Gomez <he...@gmail.com>.
For now APR support is automatically detected and eventually used.
So no problem for me to have APR and NIO.
2005/11/19, Bill Barker <wb...@wilshire.com>:
>
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <de...@tomcat.apache.org>
> Sent: Saturday, November 19, 2005 2:25 AM
> Subject: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from
> Tomcat 5.5.12 that relies on JSDK 5.0?)
>
>
> >I think we need to organize a community vote then, so that I do not waste
> >my time.
> >
> >So here we go:
> ><ballot>
> >I think the IO design for connectors used by Tomcat should be:
> >[+0] NIO selectors, etc (this means 100% NIO)
> >[+0] APR (this means 50% NIO, where NIO is only used for all the objects
> >exposed at the higher level)
> ></ballot>
> >
>
> Of course, once everybody starts using Harmony as their JVM, these will be
> the same thing ;-).
>
> For AJP/1.3, we already have all three (APR/NIO/prefork) implementations.
> From users@ it seems that there is virtually zero interest in NIO, and
> little enough in APR.
>
> While I'm interested enough to look at a NIO HTTP/1.1 implementation, I
> can't really see that the problems (e.g. unpredictible upload size) are
> solvable. Also, the cr*p implementation of NIO in Sun's Windows JVM will
> likely make it unusable on Windows.
>
>
>
> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <de...@tomcat.apache.org>
Sent: Saturday, November 19, 2005 2:25 AM
Subject: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from
Tomcat 5.5.12 that relies on JSDK 5.0?)
>I think we need to organize a community vote then, so that I do not waste
>my time.
>
>So here we go:
><ballot>
>I think the IO design for connectors used by Tomcat should be:
>[+0] NIO selectors, etc (this means 100% NIO)
>[+0] APR (this means 50% NIO, where NIO is only used for all the objects
>exposed at the higher level)
></ballot>
>
Of course, once everybody starts using Harmony as their JVM, these will be
the same thing ;-).
For AJP/1.3, we already have all three (APR/NIO/prefork) implementations.
>From users@ it seems that there is virtually zero interest in NIO, and
little enough in APR.
While I'm interested enough to look at a NIO HTTP/1.1 implementation, I
can't really see that the problems (e.g. unpredictible upload size) are
solvable. Also, the cr*p implementation of NIO in Sun's Windows JVM will
likely make it unusable on Windows.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Jess Holle <je...@ptc.com>.
P.S. I strongly believe someone at Sun should take up the NIO vs. APR
challenge and ensure that NIO outperforms APR in Tomcat usage. In other
words, Sun should ensure that a pure Java networking stack is really
best in class in real world usage. [Hopefully someone at Sun reads this
and takes this to heart...]
Until they do, however, please use whatever works best.
--
Jess Holle
Jess Holle wrote:
> Mladen Turk wrote:
>
>> So, from my point of view I see this vote as useless, because
>> anyone can create a connector using what ever technology he prefers.
>> The only valid question would be, what to use as a default one,
>> but that's a minor issue thought.
>
> As Mladen says, anyone can create a connector.
>
> Therefore, let the best connector win on its merits and let those in
> the know pursue what they believe to be the best connector approach
> based on their experience.
>
> Yes, I was one of those who asked about NIO's prospects in Tomcat way
> back when -- as it seemed worthwhile to me to fully examine a pure
> Java solution. I was arguably offbase as I do not have the level of
> experience in this area that Mladen, Remy, et al, have, but at any
> rate there was a good deal of NIO investigation around that time and
> the results were that NIO did not measure up.
>
> Until someone figures out a way to make NIO measure up to APR and
> produces numbers to show it, APR deserves to be the default.
>
> I would actually guess that the "use NIO not APR" chant comes
> primarily from those who then need APR on platforms for which they do
> not have APR binaries and don't want to deal with building or finding
> it -- yet want optimal performance.
>
> --
> Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, Nov 21, 2005 at 11:55:08AM +0100, Remy Maucherat wrote:
> Henri Gomez wrote:
> >Well why so much noise about NIO/APR ?
>
> Because I don't want to have to support 20 different connector
> technologies (you can call it a business requirement). So one has to be
> labelled as "experimental" or something. Similarly, the connector
> options right now are (for me) a bit too large.
>
Remy,
If you think this is a problem why do not you consider making Coyote API
more abstract and let people with specific requirements develop their
stuff as separate projects outside Tomcat proper, while you can
concentrate on developing one or two standard connectors that serve the
needs of the majority of users? Presently Coyote API is tightly coupled
with the default HTTP implementation, which makes development of third
party connectors difficult. Another problem is that some transport layer
aspects such as cookie handling are presently implemented in Catalina
and are intermingled with application layer aspects whereas they should
be implemented by connectors and made customizable to allow for
application specific or non-standard behaviours.
If Coyote API were more abstract and less dependent on concrete classes
in the o.a.tomcat.util package it would foster a greater ecology of
smaller projects around Tomcat and would allow interested parties to
experiment with alternative connector architectures with minimal to no
involvement on the part of Tomcat committers
Cheers,
Oleg
> >If some want to experiment APR or NIO, why can't they do their works
> >on some sort of incubations projets and when stable enough give us
> >benchmarks results.
> >
> >Benchmarks/tesings should give us information on :
> >
> >stability, speed, memory usage, IO usage and of course we should have
> >these on many platforms. For example if the alternative implementation
> >is running fast as hell on Linux but has no gain on Windows or iSeries
> >should we consider it usefull to users ?
> >
> >Also should we depend on APR on a java centric project ?
>
> Apparently not ;)
>
> >I've got no problem with APR, it's a very good piece of code, running
> >well even on exotic platforms like iSeries (and probably BS2000 jfc
> >?), but should we use a native library as the fundation of Java
> >products ?
>
> The code it replaces in the JVM is all native, written by the JVM
> vendor. For most users, it's written by Sun, and parts of it (java.nio
> select functionality, for example) have seen reliability issues. Fixing
> these kind of problems in this key component (at least in the case of a
> web server) requires updating the whole JVM. Besides Sun, and hopefully
> the other JVM vendors, I don't see how to actually do support on a NIO
> Tomcat.
>
> APR OTOH is used heavily in a similar production usage on all the
> platforms that we want to support.
>
> >Also since we're speaking about a future Tomcat redesign, shouldn't we
> >take care of the future JVM implementations ? Sun, IBM JVMs for now
> >but in the future GJC and upcoming Harmony ? If these use APR or
> >something similar in native land, should we use APR directly ?
>
> Unless the said JVMs get certified, I think only a few people are going
> to use them for real usage. BTW, yes, APR is still needed, as the JVM
> can only expose a small subset of the functionality through java.nio.
>
> >I'd like to see here pragmatics informations on gains expected when
> >using NIO/APR/WHATEVER in real life situations which is what users and
> >admins expects.
>
> I can give a real life example using AJP where the current connector
> doesn't work. If you have many front end Apache servers and few Tomcat
> servers, since the AJP connections are persistent, the backend servers
> will not be able to serve requests. APR allows using a poller for
> keepalive, so this solves the problem and the thread count on backend
> servers will remain sane.
>
> >Have a good day and peace on Tomcat Dev community
>
> Ok :)
>
> R?my
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> Well why so much noise about NIO/APR ?
Because I don't want to have to support 20 different connector
technologies (you can call it a business requirement). So one has to be
labelled as "experimental" or something. Similarly, the connector
options right now are (for me) a bit too large.
> If some want to experiment APR or NIO, why can't they do their works
> on some sort of incubations projets and when stable enough give us
> benchmarks results.
>
> Benchmarks/tesings should give us information on :
>
> stability, speed, memory usage, IO usage and of course we should have
> these on many platforms. For example if the alternative implementation
> is running fast as hell on Linux but has no gain on Windows or iSeries
> should we consider it usefull to users ?
>
> Also should we depend on APR on a java centric project ?
Apparently not ;)
> I've got no problem with APR, it's a very good piece of code, running
> well even on exotic platforms like iSeries (and probably BS2000 jfc
> ?), but should we use a native library as the fundation of Java
> products ?
The code it replaces in the JVM is all native, written by the JVM
vendor. For most users, it's written by Sun, and parts of it (java.nio
select functionality, for example) have seen reliability issues. Fixing
these kind of problems in this key component (at least in the case of a
web server) requires updating the whole JVM. Besides Sun, and hopefully
the other JVM vendors, I don't see how to actually do support on a NIO
Tomcat.
APR OTOH is used heavily in a similar production usage on all the
platforms that we want to support.
> Also since we're speaking about a future Tomcat redesign, shouldn't we
> take care of the future JVM implementations ? Sun, IBM JVMs for now
> but in the future GJC and upcoming Harmony ? If these use APR or
> something similar in native land, should we use APR directly ?
Unless the said JVMs get certified, I think only a few people are going
to use them for real usage. BTW, yes, APR is still needed, as the JVM
can only expose a small subset of the functionality through java.nio.
> I'd like to see here pragmatics informations on gains expected when
> using NIO/APR/WHATEVER in real life situations which is what users and
> admins expects.
I can give a real life example using AJP where the current connector
doesn't work. If you have many front end Apache servers and few Tomcat
servers, since the AJP connections are persistent, the backend servers
will not be able to serve requests. APR allows using a poller for
keepalive, so this solves the problem and the thread count on backend
servers will remain sane.
> Have a good day and peace on Tomcat Dev community
Ok :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Henri Gomez <he...@gmail.com>.
Well why so much noise about NIO/APR ?
If some want to experiment APR or NIO, why can't they do their works
on some sort of incubations projets and when stable enough give us
benchmarks results.
Benchmarks/tesings should give us information on :
stability, speed, memory usage, IO usage and of course we should have
these on many platforms. For example if the alternative implementation
is running fast as hell on Linux but has no gain on Windows or iSeries
should we consider it usefull to users ?
Also should we depend on APR on a java centric project ?
I've got no problem with APR, it's a very good piece of code, running
well even on exotic platforms like iSeries (and probably BS2000 jfc
?), but should we use a native library as the fundation of Java
products ?
Also since we're speaking about a future Tomcat redesign, shouldn't we
take care of the future JVM implementations ? Sun, IBM JVMs for now
but in the future GJC and upcoming Harmony ? If these use APR or
something similar in native land, should we use APR directly ?
I'd like to see here pragmatics informations on gains expected when
using NIO/APR/WHATEVER in real life situations which is what users and
admins expects.
Have a good day and peace on Tomcat Dev community
>2005/11/21, Costin Manolache <co...@gmail.com>:
> I hope you are not serious... Sorry if I sounded too critical of the
> APR code - it is a great
> piece of code in many ways, I just didn't like some (probably minor) things.
>
> If you have a problem with 'refactoring' - right now it is in sandbox,
> and I can as well
> change the package name and make it a completely separate connector.
> And I'm in no hurry to
> check anything in the main branch - the sandbox is prefect for me, so
> no need to worry about this.
>
> Costin
>
> On 11/20/05, Remy Maucherat <re...@apache.org> wrote:
> > Costin Manolache wrote:
> > > On 11/19/05, Remy Maucherat <re...@apache.org> wrote:
> > >
> > >>Costin Manolache wrote:
> > >>
> > >>>< > 1. Yes, it's how things should be done
> > >>>< > 2. No, it can be done better
> > >>>
> > >>>My opionion is (2).
> > >>
> > >>My opinion is 1. I will not participate in the design of the upcoming
> > >>Tomcat branch, then.
> > >
> > > Well, I'm not planning any 'upcoming branch' - or 'design' for that
> > > matter, just
> > > small adjustments, in sandbox first.
> >
> > Fair enough. The minute you commit your "refactoring" to the main
> > branch, I will leave this project (besides casual bugfixing).
> >
> > Rémy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Costin Manolache <co...@gmail.com>.
On 11/21/05, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > I hope you are not serious... Sorry if I sounded too critical of the
> > APR code - it is a great
> > piece of code in many ways, I just didn't like some (probably minor) things.
>
> Ok, but it helped make me realize I should maintain my own tree anyway,
> since my plans are a bit opposed to your refactoring. Also, I have
> medium term requirements which most likely are going to not fit with
> what Tomcat needs :(
Well, my need is the sandbox - so I can experiment and understand the
many things
that happened in the last years.
I didn't propose any major refactoring or new requirements - I might
need 2-3 lines of code changed in the main branch for single-jar ( it
works now with the main branch as is, but it's not
perfect ). For NIO - all I want is to see for myself how it works and
what it can do. That's what the sandbox is supposed to do.
If you want to maintain your own tree and have some new requirements -
say so, and maybe they can go in the main branch, or maybe if they are
extremely unusual ( I doubt ) in sandbox.
>
> Yes, I guess I shouldn't complain too much about code which is being
> designed in the sandbox, sorry about that :)
Again, 'designed' is a too strong word. "Toyed with" maybe.
>
> > I don't like 'alghoritms that behave in sublty different ways', or
> > duplicating extremely complex
> > classes just for 3-4 lines of code that is different. I know it is
> > simpler to write and probably maintain the code ( for people who wrote
> > it ), but not easier to understand for me.
>
> Yes, I understand that, but for me the algorithm is already a bit
> complex since, although it looks similar, the process method is
> completely different. Hopefully, it has no bugs right now !
Everything has bugs :-)
Yes, that is my point - it looks similar, but I had problems to
understand the differences. It's not
about comments or documentation - but about the code organization,
looking at the diffs was my
only way to understand.
Again, I don't want to touch something that works - just to
understand, and maybe create a similar prototype using NIO. Or maybe a
smaller APR connector that I can play with in 'coyote
standalone' mode ( I want to keep it as small as possible ). Or maybe
try to write a small NIO provider using APR ( and put to rest this
debate about what is better ). I don't know - just want to play in the
sandbox :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> I hope you are not serious... Sorry if I sounded too critical of the
> APR code - it is a great
> piece of code in many ways, I just didn't like some (probably minor) things.
Ok, but it helped make me realize I should maintain my own tree anyway,
since my plans are a bit opposed to your refactoring. Also, I have
medium term requirements which most likely are going to not fit with
what Tomcat needs :(
> If you have a problem with 'refactoring' - right now it is in sandbox,
> and I can as well
> change the package name and make it a completely separate connector.
> And I'm in no hurry to
> check anything in the main branch - the sandbox is prefect for me, so
> no need to worry about this.
Yes, I guess I shouldn't complain too much about code which is being
designed in the sandbox, sorry about that :)
> I don't like 'alghoritms that behave in sublty different ways', or
> duplicating extremely complex
> classes just for 3-4 lines of code that is different. I know it is
> simpler to write and probably maintain the code ( for people who wrote
> it ), but not easier to understand for me.
Yes, I understand that, but for me the algorithm is already a bit
complex since, although it looks similar, the process method is
completely different. Hopefully, it has no bugs right now !
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Costin Manolache <co...@gmail.com>.
I hope you are not serious... Sorry if I sounded too critical of the
APR code - it is a great
piece of code in many ways, I just didn't like some (probably minor) things.
If you have a problem with 'refactoring' - right now it is in sandbox,
and I can as well
change the package name and make it a completely separate connector.
And I'm in no hurry to
check anything in the main branch - the sandbox is prefect for me, so
no need to worry about this.
Costin
On 11/20/05, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > On 11/19/05, Remy Maucherat <re...@apache.org> wrote:
> >
> >>Costin Manolache wrote:
> >>
> >>>< > 1. Yes, it's how things should be done
> >>>< > 2. No, it can be done better
> >>>
> >>>My opionion is (2).
> >>
> >>My opinion is 1. I will not participate in the design of the upcoming
> >>Tomcat branch, then.
> >
> > Well, I'm not planning any 'upcoming branch' - or 'design' for that
> > matter, just
> > small adjustments, in sandbox first.
>
> Fair enough. The minute you commit your "refactoring" to the main
> branch, I will leave this project (besides casual bugfixing).
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> On 11/19/05, Remy Maucherat <re...@apache.org> wrote:
>
>>Costin Manolache wrote:
>>
>>>< > 1. Yes, it's how things should be done
>>>< > 2. No, it can be done better
>>>
>>>My opionion is (2).
>>
>>My opinion is 1. I will not participate in the design of the upcoming
>>Tomcat branch, then.
>
> Well, I'm not planning any 'upcoming branch' - or 'design' for that
> matter, just
> small adjustments, in sandbox first.
Fair enough. The minute you commit your "refactoring" to the main
branch, I will leave this project (besides casual bugfixing).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Costin Manolache <co...@gmail.com>.
On 11/19/05, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > < > 1. Yes, it's how things should be done
> > < > 2. No, it can be done better
> >
> > My opionion is (2).
>
> My opinion is 1. I will not participate in the design of the upcoming
> Tomcat branch, then.
Well, I'm not planning any 'upcoming branch' - or 'design' for that
matter, just
small adjustments, in sandbox first.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Costin Manolache <co...@gmail.com>.
> The question is:
>
> Do you think APR implementation, and the low leve APIs ( with all the
> duplicate code, and the current abstractions, incliuding sendfile )
> are the right ones ?
To clarify - this is not only about APR, but also *Endpoint,
TcpConnectoin/TcpConectionHandler, util.buf, util.thread,
coyote.httpd.
All were designed without considering 'mpm's correctly, and I think
that forced the current APR impl.
Costin
>
> < > 1. Yes, it's how things should be done
> < > 2. No, it can be done better
>
> My opionion is (2).
>
> Costin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> < > 1. Yes, it's how things should be done
> < > 2. No, it can be done better
>
> My opionion is (2).
My opinion is 1. I will not participate in the design of the upcoming
Tomcat branch, then.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Costin Manolache <co...@gmail.com>.
On 11/19/05, Remy Maucherat <re...@apache.org> wrote:
> Mladen Turk wrote:
> > No.
> > I would like that we accept in our (Tomcat) community much
> > more pluralism, in a similar way the Apache httpd community
> > does with mpm models.
> >
> > Neither blocking, APR or eventually NIO will ever be
> > the best solution for a particular user needs.
> > Blocking will outperform any solution for a complex
> > applications. APR will outperform any other solution
> > where large static file delivery is required, etc...
> >
> > Let's focus and actually see if the current connector
> > API allows to build those various connectors.
> > I think it does, so it's up to implementor to implement
> > the connector.
> >
> > Then, we can simply have multiple connectors that will
> > allow users to choose the optimal one according to the
> > needs, not to what we think he might need.
>
> I do not wish to have any pluralism in this area, as it is not the same
> as having the httpd pluralism. There's a functional need for this
> pluralism (process friendly OS, thread unsafe modules, etc), and besides
> we're talking about the IO API, not the thread pool.
>
> The question is: should we redesign the low level stuff *again* to be
> more abstract, etc, to be able to have as little IO API specific code in
> the connectors ? (and most likely standardize on the limited NIO feature
> set) My answer to this is no, APR is the only good solution right now,
> so there's no need for more abstraction layers.
HTTPD did that to support multiple mpms.
Remy - the actual issue is not NIO or APR.
The question is:
Do you think APR implementation, and the low leve APIs ( with all the
duplicate code, and the current abstractions, incliuding sendfile )
are the right ones ?
< > 1. Yes, it's how things should be done
< > 2. No, it can be done better
My opionion is (2).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Remy Maucherat <re...@apache.org>.
Mladen Turk wrote:
> No.
> I would like that we accept in our (Tomcat) community much
> more pluralism, in a similar way the Apache httpd community
> does with mpm models.
>
> Neither blocking, APR or eventually NIO will ever be
> the best solution for a particular user needs.
> Blocking will outperform any solution for a complex
> applications. APR will outperform any other solution
> where large static file delivery is required, etc...
>
> Let's focus and actually see if the current connector
> API allows to build those various connectors.
> I think it does, so it's up to implementor to implement
> the connector.
>
> Then, we can simply have multiple connectors that will
> allow users to choose the optimal one according to the
> needs, not to what we think he might need.
I do not wish to have any pluralism in this area, as it is not the same
as having the httpd pluralism. There's a functional need for this
pluralism (process friendly OS, thread unsafe modules, etc), and besides
we're talking about the IO API, not the thread pool.
The question is: should we redesign the low level stuff *again* to be
more abstract, etc, to be able to have as little IO API specific code in
the connectors ? (and most likely standardize on the limited NIO feature
set) My answer to this is no, APR is the only good solution right now,
so there's no need for more abstraction layers.
Pluralism in a shipped product is bad: we need to provide one good
solution at a given point in time, not 10. That solution may change in
the future, however (but I doubt it, since I don't see NIO providing any
of the platform specific stuff APR provides), and experimentation using
separate connectors is obviously ok.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Mladen Turk <mt...@apache.org>.
Jess Holle wrote:
> Mladen Turk wrote:
>
>> So, from my point of view I see this vote as useless, because
>> anyone can create a connector using what ever technology he prefers.
>> The only valid question would be, what to use as a default one,
>> but that's a minor issue thought.
>
>
> As Mladen says, anyone can create a connector.
>
> Therefore, let the best connector win on its merits and let those in the
> know pursue what they believe to be the best connector approach based on
> their experience.
>
No.
I would like that we accept in our (Tomcat) community much
more pluralism, in a similar way the Apache httpd community
does with mpm models.
Neither blocking, APR or eventually NIO will ever be
the best solution for a particular user needs.
Blocking will outperform any solution for a complex
applications. APR will outperform any other solution
where large static file delivery is required, etc...
Let's focus and actually see if the current connector
API allows to build those various connectors.
I think it does, so it's up to implementor to implement
the connector.
Then, we can simply have multiple connectors that will
allow users to choose the optimal one according to the
needs, not to what we think he might need.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
> So, from my point of view I see this vote as useless, because
> anyone can create a connector using what ever technology he prefers.
> The only valid question would be, what to use as a default one,
> but that's a minor issue thought.
As Mladen says, anyone can create a connector.
Therefore, let the best connector win on its merits and let those in the
know pursue what they believe to be the best connector approach based on
their experience.
Yes, I was one of those who asked about NIO's prospects in Tomcat way
back when -- as it seemed worthwhile to me to fully examine a pure Java
solution. I was arguably offbase as I do not have the level of
experience in this area that Mladen, Remy, et al, have, but at any rate
there was a good deal of NIO investigation around that time and the
results were that NIO did not measure up.
Until someone figures out a way to make NIO measure up to APR and
produces numbers to show it, APR deserves to be the default.
I would actually guess that the "use NIO not APR" chant comes primarily
from those who then need APR on platforms for which they do not have APR
binaries and don't want to deal with building or finding it -- yet want
optimal performance.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ?
Posted by Mladen Turk <mt...@apache.org>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> NIO is used AFAIK by Jetty and Resin, and probably others. And it's
>> the 'standard'
>> solution for select-like operations ( even if the standard is as usual
>> not the best solution ).
>
> I think we need to organize a community vote then, so that I do not
> waste my time.
>
I'm really bored with this NIO bullshit.
Once in a while someone erects, and we are going all over again
this 'to NIO or not to NIO'.
If someone wishes to write the NIO connector, fine with me,
but I'll be -1 (read VETO) if that would lead to redesign of Tomcat
in a way that simple blocking connector implementation will
be impossible to create.
IMHO anything but thread-per-request (at least) for any http-like
application (not a simple file delivery) is ineffective. Even if
some day the Servlet spec will allow async/event behavior
(that would be over engineering in its true meaning),
from whatever point of view, by pure theory it would be a peace of crap.
So, from my point of view I see this vote as useless, because
anyone can create a connector using what ever technology he prefers.
The only valid question would be, what to use as a default one,
but that's a minor issue thought.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing
from Tomcat 5.5.12 that relies on JSDK 5.0?)
Posted by Mladen Turk <mt...@apache.org>.
Yoav Shapira wrote:
>
> I too vote both, and the classical style as well. Besides Costin's reasoning,
> with which I largely agree, I have also been seeing more and more people use
> Java web servers as the front-end, no less. And I want to keep the 100% pure
> Java option available, preferably as the default, even if it's a few percentage
> points worse performance.
>
Right, but even now, it's 100% pure Java.
Highperformance (APR) is enabled by the installation of the needed
native libraries, so I don't see the need for refactoring.
If Costing thinks the exiting code needs refactoring, well, we have
SVN, so he can create a branch and offer a better solution.
Then we can discuss and (eventually vote) for inclusion in head.
> On a related note, we can add a server-highperformance.xml configuration file
> that ships with Tomcat, and uses APR and whatever else we can think of to
> increase perfdormance out of the box. This is similar to the multiple
> httpd-XXX.conf files that ship with the HTTP web server.
>
Sure, the proper example would be fine. Even the server-openssl.xml
too, etc...
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
> So here we go:
> <ballot>
> I think the IO design for connectors used by Tomcat should be:
> [ X ] NIO selectors, etc (this means 100% NIO)
> [ X ] APR (this means 50% NIO, where NIO is only used for all the objects
> exposed at the higher level)
> </ballot>
I too vote both, and the classical style as well. Besides Costin's reasoning,
with which I largely agree, I have also been seeing more and more people use
Java web servers as the front-end, no less. And I want to keep the 100% pure
Java option available, preferably as the default, even if it's a few percentage
points worse performance.
On a related note, we can add a server-highperformance.xml configuration file
that ships with Tomcat, and uses APR and whatever else we can think of to
increase perfdormance out of the box. This is similar to the multiple
httpd-XXX.conf files that ship with the HTTP web server.
Yoav
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org