You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bruce Keats <br...@gmail.com> on 2005/11/18 16:00:57 UTC
Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Hi,
Given the discussion on missing JSSE15SocketFactory because tomcat
5.5.12was build using JAVA
1.4, I am trying to determine if I need to rebuild the whole source tree
under JSDK 5.0 or just the missing JSSE15SocketFactory. In order to make
that judgement call, I need to understand if there is any other
functionality that is missing.
Other than JSSE15SocketFactory, is there any other functionality missing
from tomcat 5.5.12 because it was build using JAVA 1.4?
Bruce
Re: Any other functionality missing from Tomcat 5.5.12 that relies
on JSDK 5.0?
Posted by Martin van den Bemt <ml...@mvdb.net>.
Sorry for entering in this discussion..
Remy Maucherat wrote:
> Costin Manolache wrote:
>> 'accepted' solution.
>
>
> The truth is, few people are using Java web servers, and it's not going
> to change. I'm curious to know how NIO is a well accepted solution for
> web servers, BTW.
Can you eleborate on why most people aren't going to use java web servers ?
(besides the obvious ones about not everyone is having java, etc..)
Mvgr,
Martin
---------------------------------------------------------------------
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
[VOTE] APR or NIO ? (was:Re: Any other functionality missing from
Tomcat 5.5.12 that relies on JSDK 5.0?)
Posted by Remy Maucherat <re...@apache.org>.
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: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Posted by Costin Manolache <co...@gmail.com>.
On 11/18/05, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > For C++ servers - yes.
> > For Java servers - is anyone else using it besides tomcat ? Even in
> > tomcat - how many
> > people are using the bindings ( compared with the non-apr connector ) ?
> >
> > Unfortunately - NIO is the well-accepted solution for java servers (
> > all except tomcat
> > are using it ). We know APR is better - but can't pretend it's an
> > 'accepted' solution.
>
> The truth is, few people are using Java web servers, and it's not going
> to change. I'm curious to know how NIO is a well accepted solution for
> web servers, BTW.
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'm sorry, I like APR, but I can't like the current implementation (
> > except as a good
> > initial step ).
>
> Again, I completely disagree. The low level code is small enough that an
> abstraction layer is useless. Similarly, a lot of the code in j-t-c/util
> should go (starting with the "threads" package).
Agree, the threads package shouldn't be used as an API - and a lot of code in
j-t-c/util should be deprecated. One of the nice things about NIO is
that you can't
get rid of a lot of some stuff.
Duplicating the entire HTTP parser class just because you don't want a
small abstraction
( which was actually already there ) is not right.
> To get down to the root of the problem, I don't like the argument that
> NIO is any good as an IO API. Besides the (many) utility classes like
> the buffers, and as a JNI access method, both of which can be used
> without sencond thoughts (and are actually used right now), all the
> actual IO code is still all native (no surprise) and the Java API on top
> is over engineered. It doesn't make sense to me.
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 ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any other functionality missing from Tomcat 5.5.12 that relies
on JSDK 5.0?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> For C++ servers - yes.
> For Java servers - is anyone else using it besides tomcat ? Even in
> tomcat - how many
> people are using the bindings ( compared with the non-apr connector ) ?
>
> Unfortunately - NIO is the well-accepted solution for java servers (
> all except tomcat
> are using it ). We know APR is better - but can't pretend it's an
> 'accepted' solution.
The truth is, few people are using Java web servers, and it's not going
to change. I'm curious to know how NIO is a well accepted solution for
web servers, BTW.
> Not a new abstraction layer - just adjustments to the current one.
> For example - add the 'long' socket to TcpConnection - and adjust comments in
> TcpConnectionHandler - so it can be used instead of the Handler. Then most Apr
> classes could extend the corresponding non-APR classes, and only
> override what's
> different.
>
> It's not the perfect abstraction - but if you also add NIO, you could
> later extract
> a base class that has none of the apr/nio/classic methods, and avoid
> duplication.
> Adding NIO in the same way as APR was added would be a nightmare - the current
> APR code is already messy ( Sendfile for example ).
>
> I'm sorry, I like APR, but I can't like the current implementation (
> except as a good
> initial step ).
Again, I completely disagree. The low level code is small enough that an
abstraction layer is useless. Similarly, a lot of the code in j-t-c/util
should go (starting with the "threads" package).
To get down to the root of the problem, I don't like the argument that
NIO is any good as an IO API. Besides the (many) utility classes like
the buffers, and as a JNI access method, both of which can be used
without sencond thoughts (and are actually used right now), all the
actual IO code is still all native (no surprise) and the Java API on top
is over engineered. It doesn't make sense to me.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
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/18/05, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > So for NIO - we should create another copy of 5 large files ? Most of
> > the functions are complete duplicates - a simple extend would eliminate
> > them.
> >
> > The problems are in few abstractions - like Handler - which can be
> > easily fixed to
> > accomodate NIO / APR or traditional.
> >
> > NIO is a valid solution - and may be as fast as APR, in particular
> > with JDK1.6 -
> > and it avoids the JNI layer.
> >
> > I like APR more too - but I don't think it's wise to say there will be
> > no better solution
> > in the future :-) It just happens that today APR is faster - and has a
> > lot of features beyond
> > NIO.
> >
> > IMO the future is in features integrated at the low-level with the VM
> > - in particular
> > if they can bypass JNI or use non-garbage-collected heaps ( as in
> > real-time java ). It
> > would be hard for any JNI solution to beat this - but of course,
> > that's future, not so easy
> > to predict...
>
> I completely disagree. APR is a well accepted IO impl for webservers
> (obviously), and works very well.
For C++ servers - yes.
For Java servers - is anyone else using it besides tomcat ? Even in
tomcat - how many
people are using the bindings ( compared with the non-apr connector ) ?
Unfortunately - NIO is the well-accepted solution for java servers (
all except tomcat
are using it ). We know APR is better - but can't pretend it's an
'accepted' solution.
> There's room for experimentation as
> separate implementations, but should NIO get better and support the
> features we need (somehow, I doubt the second one will ever be the case
> ...), there's going to be ample time to switch to it later (emphasis on
> later; Java 6 as the Tomcat target is quite far away). In the meantime,
> I don't see the point of yet another abstraction layer.
Not a new abstraction layer - just adjustments to the current one.
For example - add the 'long' socket to TcpConnection - and adjust comments in
TcpConnectionHandler - so it can be used instead of the Handler. Then most Apr
classes could extend the corresponding non-APR classes, and only
override what's
different.
It's not the perfect abstraction - but if you also add NIO, you could
later extract
a base class that has none of the apr/nio/classic methods, and avoid
duplication.
Adding NIO in the same way as APR was added would be a nightmare - the current
APR code is already messy ( Sendfile for example ).
I'm sorry, I like APR, but I can't like the current implementation (
except as a good
initial step ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any other functionality missing from Tomcat 5.5.12 that relies
on JSDK 5.0?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> So for NIO - we should create another copy of 5 large files ? Most of
> the functions are complete duplicates - a simple extend would eliminate
> them.
>
> The problems are in few abstractions - like Handler - which can be
> easily fixed to
> accomodate NIO / APR or traditional.
>
> NIO is a valid solution - and may be as fast as APR, in particular
> with JDK1.6 -
> and it avoids the JNI layer.
>
> I like APR more too - but I don't think it's wise to say there will be
> no better solution
> in the future :-) It just happens that today APR is faster - and has a
> lot of features beyond
> NIO.
>
> IMO the future is in features integrated at the low-level with the VM
> - in particular
> if they can bypass JNI or use non-garbage-collected heaps ( as in
> real-time java ). It
> would be hard for any JNI solution to beat this - but of course,
> that's future, not so easy
> to predict...
I completely disagree. APR is a well accepted IO impl for webservers
(obviously), and works very well. There's room for experimentation as
separate implementations, but should NIO get better and support the
features we need (somehow, I doubt the second one will ever be the case
...), there's going to be ample time to switch to it later (emphasis on
later; Java 6 as the Tomcat target is quite far away). In the meantime,
I don't see the point of yet another abstraction layer.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
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/18/05, Remy Maucherat <re...@apache.org> wrote:
> >
> > I'm not even sure if/how can we use OpenSSL via APR ( I found some
> > code, and it should work ). The whole connection layer should be
>
> It actually works.
I'm happy I got regular HTTP/APR working, wasn't easy :-)
>
> > refactored to allow better abstraction for APR, NIO, old-style
> > sockets/threads... The current approach in APR ( duplicate everything
> > ) may be good for quick tests, but it can't be the long term solution
> > ( some people like to add a NIO equivalent ).
>
> I'm perfectly fine with it. I prefer duplicating things than having a
> complex abstraction layer (if you compare the APR API with the NIO/Java
> IO API, you'll see APR is simpler, so the connector code can be a bit
> simpler - for equivalent functionality at least). At this point, I see
> non APR connectors as having no future production wise.
So for NIO - we should create another copy of 5 large files ? Most of
the functions are complete duplicates - a simple extend would eliminate
them.
The problems are in few abstractions - like Handler - which can be
easily fixed to
accomodate NIO / APR or traditional.
NIO is a valid solution - and may be as fast as APR, in particular
with JDK1.6 -
and it avoids the JNI layer.
I like APR more too - but I don't think it's wise to say there will be
no better solution
in the future :-) It just happens that today APR is faster - and has a
lot of features beyond
NIO.
IMO the future is in features integrated at the low-level with the VM
- in particular
if they can bypass JNI or use non-garbage-collected heaps ( as in
real-time java ). It
would be hard for any JNI solution to beat this - but of course,
that's future, not so easy
to predict...
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any other functionality missing from Tomcat 5.5.12 that relies
on JSDK 5.0?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Check the build.xml files, look for 'unless'.
>
> Probably the right solution to avoid this would be to stop using
> 'unless' and ant checks,
> and instead move all the 'conditional' code in separate targets and
> jar files. In particular, the
> whole SSL stuff is an unpredictible mess.
>
> I'm not even sure if/how can we use OpenSSL via APR ( I found some
> code, and it should work ). The whole connection layer should be
It actually works.
> refactored to allow better abstraction for APR, NIO, old-style
> sockets/threads... The current approach in APR ( duplicate everything
> ) may be good for quick tests, but it can't be the long term solution
> ( some people like to add a NIO equivalent ).
I'm perfectly fine with it. I prefer duplicating things than having a
complex abstraction layer (if you compare the APR API with the NIO/Java
IO API, you'll see APR is simpler, so the connector code can be a bit
simpler - for equivalent functionality at least). At this point, I see
non APR connectors as having no future production wise.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Posted by Costin Manolache <co...@gmail.com>.
Check the build.xml files, look for 'unless'.
Probably the right solution to avoid this would be to stop using
'unless' and ant checks,
and instead move all the 'conditional' code in separate targets and
jar files. In particular, the
whole SSL stuff is an unpredictible mess.
I'm not even sure if/how can we use OpenSSL via APR ( I found some
code, and it should work ). The whole connection layer should be
refactored to allow better abstraction for APR, NIO, old-style
sockets/threads... The current approach in APR ( duplicate everything
) may be good for quick tests, but it can't be the long term solution
( some people like to add a NIO equivalent ).
Costin
On 11/18/05, Bruce Keats <br...@gmail.com> wrote:
> Hi,
> Given the discussion on missing JSSE15SocketFactory because tomcat
> 5.5.12was build using JAVA
> 1.4, I am trying to determine if I need to rebuild the whole source tree
> under JSDK 5.0 or just the missing JSSE15SocketFactory. In order to make
> that judgement call, I need to understand if there is any other
> functionality that is missing.
> Other than JSSE15SocketFactory, is there any other functionality missing
> from tomcat 5.5.12 because it was build using JAVA 1.4?
> Bruce
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org