tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [VOTE] APR or NIO ?
Date Sat, 19 Nov 2005 16:35:45 GMT
On 11/19/05, Remy Maucherat <> 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).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message