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.
than JSSE15SocketFactory, is there any other functionality missing
from tomcat 5.5.12 because it was build using JAVA 1.4?
Bruce

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 SSL via APR ( I found some
code, and it should work ). The whole connection layer should be
refactored to allow better abstraction for APR, NI, 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 NI equivalent ).

Costin

11/18/05, Bruce Keats <brucekeats (AT) gmail (DOT) comwrote:
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.
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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) 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 SSL 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, NI, 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 NI 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 NI/Java
I 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

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/18/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:

I'm not even sure if/how can we use SSL 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, NI, 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 NI 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 NI/Java
I 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 NI - 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 NI / APR or traditional.

NI 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
NI

IM 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Costin Manolache wrote:
So for NI - 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 NI / APR or traditional.

NI 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
NI

IM 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 I impl for webservers
(obviously), and works very well. There's room for experimentation as
separate implementations, but should NI 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

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/18/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
Costin Manolache wrote:
So for NI - 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 NI / APR or traditional.

NI 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
NI

IM 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 I 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 - NI 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 NI 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 NI, you could
later extract
a base class that has none of the apr/nio/classic methods, and avoid
duplication.
Adding NI 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) 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 - NI 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 NI 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 NI, you could
later extract
a base class that has none of the apr/nio/classic methods, and avoid
duplication.
Adding NI 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
NI is any good as an I 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 I code is still all native (no surprise) and the Java API on top
is over engineered. It doesn't make sense to me.

R

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/18/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
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 - NI 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 NI is a well accepted solution for
web servers, BTW.

NI 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. of the nice things about NI 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
NI is any good as an I 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 I 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 NI 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Costin Manolache wrote:
NI 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 NI,
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 NI 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 I design for connectors used by Tomcat should be:
[ ] NI selectors, etc (this means 100% NI)
[ ] APR (this means 50% NI, where NI is only used for all the objects
exposed at the higher level)
</ballot>

, I vote APR.

R

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Remy Maucherat wrote:
Costin Manolache wrote:

>NI 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 NI bull****.
in a while someone erects, and we are going all over again
this 'to NI or not to NI'.

If someone wishes to write the NI connector, fine with me,
but I'll be -1 (read VET) if that would lead to redesign of Tomcat
in a way that simple blocking connector implementation will
be impossible to create.

IMH 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) 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 NI 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) 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 NI 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 S, thread unsafe modules, etc), and besides
we're talking about the I 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 I API specific code in
the connectors ? (and most likely standardize on the limited NI 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 NI providing any
of the platform specific stuff APR provides), and experimentation using
separate connectors is obviously ok.

R

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

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 NI 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/19/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
<ballot>
I think the I design for connectors used by Tomcat should be:
[X] NI selectors, etc (this means 100% NI)
[X] APR (this means 50% NI, where NI is only used for all the objects
exposed at the higher level)
</ballot>

, 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 I

Costin

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/19/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
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 NI 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 S, thread unsafe modules, etc), and besides
we're talking about the I 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 I API specific code in
the connectors ? (and most likely standardize on the limited NI 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 NI 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

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,
, 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/19/05, Yoav Shapira <yoavs (AT) apache (DOT) orgwrote:

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 IM 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) 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

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/19/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Message
From: "Remy Maucherat" <remm (AT) apache (DOT) org>
To: "Tomcat Developers List" <dev (AT) tomcat (DOT) apache.org>
Sent: Saturday, November 19, 2005 2:25 AM
Subject: [VTE] APR or NI ? (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 I design for connectors used by Tomcat should be:
>[+0] NI selectors, etc (this means 100% NI)
>[+0] APR (this means 50% NI, where NI is only used for all the objects
>exposed at the higher level)
></ballot>
>

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/NI/prefork) implementations.
From users@ it seems that there is virtually zero interest in NI, and
little enough in APR.

While I'm interested enough to look at a NI 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 NI 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 CNFIDENTIAL. 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

For now APR support is automatically detected and eventually used.

So no problem for me to have APR and NI

2005/11/19, Bill Barker <wbarker (AT) wilshire (DOT) com>:

Message
From: "Remy Maucherat" <remm (AT) apache (DOT) org>
To: "Tomcat Developers List" <dev (AT) tomcat (DOT) apache.org>
Sent: Saturday, November 19, 2005 2:25 AM
Subject: [VTE] APR or NI ? (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 I design for connectors used by Tomcat should be:
>[+0] NI selectors, etc (this means 100% NI)
>[+0] APR (this means 50% NI, where NI is only used for all the objects
>exposed at the higher level)
></ballot>
>
>
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/NI/prefork) implementations.
From users@ it seems that there is virtually zero interest in NI, and
little enough in APR.

While I'm interested enough to look at a NI 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 NI 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 CNFIDENTIAL. 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
--

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Costin Manolache wrote:
11/19/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:

>>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

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

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

11/20/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
Costin Manolache wrote:
11/19/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
>
>>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

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
--

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Well why so much noise about NI/APR ?

If some want to experiment APR or NI, 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, I 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 NI/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 <costin (AT) gmail (DOT) 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

11/20/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
Costin Manolache wrote:
11/19/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
>
>>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

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
>
>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
--

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) 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.

, 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

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Henri Gomez wrote:
Well why so much noise about NI/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 NI, 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, I 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 NI
Tomcat.

APR TH 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 NI/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

:)

R

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

Mon, Nov 21, 2005 at 11:55:08AM +0100, Remy Maucherat wrote:
Henri Gomez wrote:
>Well why so much noise about NI/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,


>If some want to experiment APR or NI, 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, I 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 NI
Tomcat.

APR TH 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 NI/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

:)

R?my

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

11/21/05, Remy Maucherat <remm (AT) apache (DOT) orgwrote:
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.

, 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 NI - 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 NI maybe a
smaller APR connector that I can play with in 'coyote
standalone' mode ( I want to keep it as small as possible ). maybe
try to write a small NI 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 (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org