Pier Fumagalli wrote: > "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
Peace Pier. I think there's a misunderstanding ;-) >>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... Coyote does that better / is closer to the actual webserver architecture, so this should address the concern. Hence WARP for Coyote :) >>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) I was talking about a *long term* possibility (3-5 years or so) ;-) Not tommorrow, not the day after. A VM solves the buffer overflow related bugs. Tomcat still has reliability problems, but it has no buffer overflow issues (at least with the Java HTTP/1.1 stack). Now we have to work on the reliability part. With everyone helping pushing the same codebase, it may finally happen. >>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... I contend it could be faster / more memory efficient. >>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... Great. Might be hard to convince anyone after the Webapp incident, though. If you manage to convince them, then it would mean it is outstanding stuff, so I'll sit back and watch you do the job (and I'll be at the beach enjoying the sun) :-) >>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... I guess both Costin and I suck "because you say so", to quote Costin's words. > Remy, just one question: what web server and servlet container is Sun using > for java.sun.com? Tomcat? NOPE! I don't care what they are using. As long as they are paying my salary, they must think it is decent enough. >>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. Well, obviously with the amount of changes that went in Jasper, the first beta was bound to have issues (that's why we do betas, I suppose). It will get there. >>>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... I agree, so that's why there are almost zero new features in the 5.0 proposal. Except the new specs, but I was told this was a requirement ;-) Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
