"Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> Working as well as possible with Apache is my objective.
> Providing a great Java web server is also my objective.
To some extents, these two objectives contradict each other. You can see
this already in the design of Catalina, and in the hacks that I had to do to
make webapp work... WebApp relies on the concept of a web-application
deployed somewhere, what goes between that and the HTTP request I get from
my client, is of no concerns of the servlet container...
> Also, you have to remember that in the long run VM based web servers may
> (huge speculation; no flames please) attract some interest eventually
> because of their inherent security advantages over native web servers.
You still have to fight about a 56% of market share that Apache has...
Plus, I strongly disagree in using a full-java solution for high
availability: first of all, let's tart with the rule of thumb that IF
something needs to go wrong IT WILL go wrong...
Assume my case: I have a hugely loaded web-application (around 8 millions
request day), now, the application goes down, for any reason (last one was
that the mail server got down, too many messages in the queue, BOOM,
outofmemoryexception).
When I restart my application, it might take up to 5/6 minutes (pulling data
out of the databases to initialize the cache, building search indexes, a
huge crapload of stuff)...
Now, am I ready NOT to serve http requests for 5/6 minutes? Nope, because I
possibly will end up interfering with around 10k users which in those 5/6
minutes will be browsing my site...
Now, a one-tier architecture, for what matters to me, is absolutely
unreliable, and for what matters to me, doesn't scale...
If my application, and my stack is down, all I can do is reject requests,
while if we envision an HTTP server separated from the servlet container, I
can have "fallback" servlet containers, I can change configurations on the
fly and have requests served by another servlet container, I can do
_something_... If my whole application is on the same tier of the HTTP
stack, I'm stuck...
So, IMO, there is no whatsoever need to have a highly reliable HTTP stack
written in Java... Plenty of native solutions give you the answer, and for
what matters to me, having a N-tiered model has only advantages (that's what
I've been preaching since 1998)
>> As I said, I am not confident in Tomcat as of _NOW_ to run on _MY_
>> production site. I don't want to think about a new upcoming and improved
>> release when IMO, there's still so much crap to do with the current code
>> base.
>
> I aim to change your mind eventually. I don't think you give the new
> code a fair trial, though.
My only fair trial is: putting it on production site: observing load
climbing up to 8 when it's 3.4 as a base, switching back to old fart
ServletExec+Apache...
>> That would be a waste of time and CPU resources... You're looking in the
>> wrong direction... To get performance, and reliability, all you have to do
>> is simplify the code, removing layer after layer... Not adding them...
>
> Implementing both the connector AND the servlet API in the same classes
> is IMO the definition of messy code. So I am convinced that, to keep it
> clean, you have to have one additional layer.
Might be messy, but for sure it's fast...
> If everyone decides to think like you do, then I'll leave those persons
> in charge of the maintenance of the connectors.
I will make up my mind and maybe do a nice proposal, like we did for 4.0...
I'll let code and performances speak for themselves, if I get around to do
it...
> It is likely however that most people here are strongly against going
> back to the unified model.
It is likely, however, that people are _still_ nowdays scared about
switching from Jserv to Tomcat on their production environments, and it's
still nowdays a problem the fact that they're switching from Jserv to other
servlet containers, such as Jrun, Resin and ServletExec...
> I recommend you review the Coyote HTTP/1.1 protocol handler, and tell me
> if you really think the extra layer adds any kind of performance
> penalty, or any added complexity.
I reviewed the Apache Web Server HTTP protocol handler, and that works for
me...
> Personally, I think the Coyote HTTP/1.1 design makes me give up 1 or 2%
> of absolute maximum performance (ie, it's negligible), but in return the
> programming model is much simpler, and therefore I am able to get a lot
> closer from the theorical limit.
Remy, just one question: what web server and servlet container is Sun using
for java.sun.com? Tomcat? NOPE!
>> FWIW, I don't care about other containers... And I won't care about future
>> revisions of Tomcat until this one "works for me"...
>
> I think this is reasonable :)
> I hope 4.1 will be that one, unless 4.0.4 + webapp does the job for you
> already.
Nope... It doesn't... It's close to what I want, but not yet there... I hope
to be able to put it in production by August.
>> Or you loose interest when you see that no matter what you do, noone even
>> listens to what you say...
>
> Personally, I think the feature completeness will happen first. But you
> obviously don't hink the same way I do, so ....
Features features features... Features are NOTHING if you don't have
reliability... But that's my vision, that's what I want to get. Features are
not important...
Pier
--
[Perl] combines all the worst aspects of C and Lisp: a billion of different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
