You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by cm...@yahoo.com on 2000/11/08 19:55:59 UTC
No revolution today
Hi,
After a lot of thinking, I decided to give up ( at least temporary ) my
plans for a tomcat revolution. It was very tempting, but I don't think
it's the right thing to do - evolution is still the best way to go :-)
It is important that tomcat3 has a design that allows support for future
versions of the servlet API, but if tomcat developers don't want to see it
happen - so be it. When Servlet2.3 will be final and in wide use, there is
nothing that can stop someone from providing the module that supports it (
not necesarily from apache site ).
But for now it's important to continue to improve the foundation.
My focus will continue to be on Tomcat3.3, in fixing the encoding
problems and on improving the performance. We are not yet the best
servlet container - so there is still work to do.
If you believe that tomcat3 can't be the best container, and a different
model is better suited for that - that's perfect, as long as the code you
write is reusable everyone will benefit. And I'm sure the users will
choose whatever it's better for them, regardless of version
numbers. It's open source - and so far the better code has survived
regardless of politics.
The rules are still there - after a release, the main branch is open for
the development of the next release, and as long as we are improving I
don't think anyone can stop the evolution.
Regarding the other issues ( webdav, etc ) - if the author believes it's
not right to provide support for webdav in tomcat3.3 I'll move the
implementation in proposals. It's just a webapplication that should work
on any container, who needs it can get it without being included in the
standard distribution.
Regarding the Resource abstraction and the caching code ( that are used in
webdav), those will probably go into tomcat3.3 - unless you can vote that
better performance is bad for tomcat. Same thing should happen with the
HTTP1.1 implementation - it's great code and it shouldn't be tied to a
particular container design.
Costin
Re: No revolution today
Posted by Matthew Dornquast <ma...@webhelp.com>.
> In our situation, we plan to use multiple virtual hosts, each with its
> own root context. That makes the URLs shorter and easier for people to
> work with. It also lets you more easily move/copy one context to
> another without having to fix all the links.
We use many virtual hosts today in production,
however they all share the same root context.
To some this might seem counter-intuitive.
It actually does make sense if you're using the MVC pattern and
you use virtual hosts to define a cluster of alternate views.
Just because the "View" is changing doesn't mean the serlvet (controller)
isn't identical. We like to avoid loading lots of VM's.
In fact, we have base servlets than are extended by host specific
servlets for specific views.
It also gives you flexibility in the "route" people take to your servers.
Hostname A might have hot spares, while hostname B has a cluster of
servers behind it.
> If anybody is interested in the patches, let me know and I'll post them
> to the list again.
Would your patches work in the above scenario as well?
If so, I'd love to have them!
Is their any reason their not merged into the core 3.2 code?
> I'd also like to cast my vote for a production quality release and
> continued development of tomcat 3.x for production use.
Definitely want to chime in and agree on this. We're still running 3.1 in
production on
8 web servers. It's slow, it doesn't let us do sessions (aforementioned
reasons) but hey--
It's stable.
-Matthew
Re: No revolution today
Posted by kenneth topp <ca...@prodigy.net>.
I'm interested in these patches.
Also, I'm interested in the issues with the issues with root contexts (the
thread name on tomcat-dev or .java file)
Thanks,
Kenneth Topp
On Thu, 9 Nov 2000, Paul Frieden wrote:
> In our situation, we plan to use multiple virtual hosts, each with its
> own root context. That makes the URLs shorter and easier for people to
> work with. It also lets you more easily move/copy one context to
> another without having to fix all the links.
>
> I've posted patches that make this work for us in the past, along with
> several other patches for cookie behavior. We're not running this in
> production yet, but I've had load balancing working as expected (as far
> as I can tell) with mod_jk and tomcat_32. I don't have the load
> balancing hardware available for testing, but I've set up DNS round
> robin, as well as things like killing apache on one host to force it to
> the other and the sessions being routed properly.
>
> If anybody is interested in the patches, let me know and I'll post them
> to the list again. One fixed root context load balancing (at least for
> us), cookie deletion, session cookie selection, and one that prevents
> session cookies other than the valid one from being leaked into a
> webapp.
>
> I'd also like to cast my vote for a production quality release and
> continued development of tomcat 3.x for production use. Tomcat 4.0 may
> be elegant, but what I need right now is robust and fast Servlet 2.2/JSP
> 1.1.
>
> Paul Frieden
>
>
>
> Joseph Chiu wrote:
> >
> > Matthew,
> >
> > In my environment, I wanted to force all contexts to be in the root context.
> >
> > So, my point is -- if you only need the root context (one context only!), my
> > kludge works. If you want root context and non-root contexts to both
> > coexist, then you'll need to modify my kludge to NOT force the context to
> > the root context. You'll have to test it to see if it works for you
> > (because I haven't). I think Andrew Cowie did the latter (not force the
> > contexts to the root context), but I don't want to speak for him.
> >
> > If you need multiple contexts without the root context, then the existing
> > Tomcat should be perfectly fine.
> >
> > Joseph
> > -----Original Message-----
> > From: Matthew Dornquast [mailto:matthew.dornquast@webhelp.com]
> > Sent: Thursday, November 09, 2000 2:28 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: No revolution today
> >
> > > Well, but if you don't need the root-context, then the load balancing
> > > *should* work with other contexts. You are using mod_jserv with APJ
> > > Balancesets, right?
> >
> > Right Jospeh!
> >
> > So how important is it to support load balancing of root contexts?
> >
> > How many users use the root context?
> >
> > >From where I sit, it's a requirement, I have no other option.
> >
> > I don't want to go into the reasons as to why this is, (Unless there is a
> > great deal of interest)
> > but I do wonder how many others are doing it like I am?
> >
> > > its a big change. fix for 3.3 ? This would seriously nuke loadbalancing
> > > for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable
> > > out after so many months (years?).
> >
> > I wish I knew if it was a big change or not.
> >
> > When I was trying to do it, it felt like it was more of a mod_jserv issue
> > and had little/nothing to do with tomcat.
> >
> > It seemed like mod_serv config parser just couldn't grok what I was telling
> > it.
> >
> > (Kudos to the designer(s) of the API for mod_jserv, I thought it well
> > thought out and
> > easy to config given the amount of power/flexibility they were giving me.)
> >
> > 3.2 Stable is very important, at a minimum however, documentation should be
> > updated to state it's not supported in 3.2 root context.
> >
> > -matthew
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: No revolution today
Posted by Paul Frieden <pf...@dChain.com>.
In our situation, we plan to use multiple virtual hosts, each with its
own root context. That makes the URLs shorter and easier for people to
work with. It also lets you more easily move/copy one context to
another without having to fix all the links.
I've posted patches that make this work for us in the past, along with
several other patches for cookie behavior. We're not running this in
production yet, but I've had load balancing working as expected (as far
as I can tell) with mod_jk and tomcat_32. I don't have the load
balancing hardware available for testing, but I've set up DNS round
robin, as well as things like killing apache on one host to force it to
the other and the sessions being routed properly.
If anybody is interested in the patches, let me know and I'll post them
to the list again. One fixed root context load balancing (at least for
us), cookie deletion, session cookie selection, and one that prevents
session cookies other than the valid one from being leaked into a
webapp.
I'd also like to cast my vote for a production quality release and
continued development of tomcat 3.x for production use. Tomcat 4.0 may
be elegant, but what I need right now is robust and fast Servlet 2.2/JSP
1.1.
Paul Frieden
Joseph Chiu wrote:
>
> Matthew,
>
> In my environment, I wanted to force all contexts to be in the root context.
>
> So, my point is -- if you only need the root context (one context only!), my
> kludge works. If you want root context and non-root contexts to both
> coexist, then you'll need to modify my kludge to NOT force the context to
> the root context. You'll have to test it to see if it works for you
> (because I haven't). I think Andrew Cowie did the latter (not force the
> contexts to the root context), but I don't want to speak for him.
>
> If you need multiple contexts without the root context, then the existing
> Tomcat should be perfectly fine.
>
> Joseph
> -----Original Message-----
> From: Matthew Dornquast [mailto:matthew.dornquast@webhelp.com]
> Sent: Thursday, November 09, 2000 2:28 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: No revolution today
>
> > Well, but if you don't need the root-context, then the load balancing
> > *should* work with other contexts. You are using mod_jserv with APJ
> > Balancesets, right?
>
> Right Jospeh!
>
> So how important is it to support load balancing of root contexts?
>
> How many users use the root context?
>
> >From where I sit, it's a requirement, I have no other option.
>
> I don't want to go into the reasons as to why this is, (Unless there is a
> great deal of interest)
> but I do wonder how many others are doing it like I am?
>
> > its a big change. fix for 3.3 ? This would seriously nuke loadbalancing
> > for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable
> > out after so many months (years?).
>
> I wish I knew if it was a big change or not.
>
> When I was trying to do it, it felt like it was more of a mod_jserv issue
> and had little/nothing to do with tomcat.
>
> It seemed like mod_serv config parser just couldn't grok what I was telling
> it.
>
> (Kudos to the designer(s) of the API for mod_jserv, I thought it well
> thought out and
> easy to config given the amount of power/flexibility they were giving me.)
>
> 3.2 Stable is very important, at a minimum however, documentation should be
> updated to state it's not supported in 3.2 root context.
>
> -matthew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: No revolution today
Posted by Joseph Chiu <jc...@spun.com>.
Matthew,
In my environment, I wanted to force all contexts to be in the root context.
So, my point is -- if you only need the root context (one context only!), my
kludge works. If you want root context and non-root contexts to both
coexist, then you'll need to modify my kludge to NOT force the context to
the root context. You'll have to test it to see if it works for you
(because I haven't). I think Andrew Cowie did the latter (not force the
contexts to the root context), but I don't want to speak for him.
If you need multiple contexts without the root context, then the existing
Tomcat should be perfectly fine.
Joseph
-----Original Message-----
From: Matthew Dornquast [mailto:matthew.dornquast@webhelp.com]
Sent: Thursday, November 09, 2000 2:28 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: No revolution today
> Well, but if you don't need the root-context, then the load balancing
> *should* work with other contexts. You are using mod_jserv with APJ
> Balancesets, right?
Right Jospeh!
So how important is it to support load balancing of root contexts?
How many users use the root context?
Re: No revolution today
Posted by Matthew Dornquast <ma...@webhelp.com>.
> Well, but if you don't need the root-context, then the load balancing
> *should* work with other contexts. You are using mod_jserv with APJ
> Balancesets, right?
Right Jospeh!
So how important is it to support load balancing of root contexts?
How many users use the root context?
RE: No revolution today
Posted by Joseph Chiu <jc...@spun.com>.
Well, but if you don't need the root-context, then the load balancing
*should* work with other contexts. You are using mod_jserv with APJ
Balancesets, right?
Joseph
-----Original Message-----
From: yhs@mimic.onesourcecorp.com [mailto:yhs@mimic.onesourcecorp.com]
Sent: Thursday, November 09, 2000 12:46 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: No revolution today
On Thu, 9 Nov 2000, Matthew Dornquast wrote:
> re>Our site (http://www.spun.com) runs multiple Apache servers with load
> balancers ("rotator box like BigIP") that distribute traffic over the
Apache
> servers. We have a farm of Tomcat servers. The session API's work for
us.
> The only problem is that Tomcat, as distributed, does not allow load
> balancing persistence for the root context. We hacked a way around that
> (search the archives if you're interested) - but it's an admitted kludge.
> --------------
>
> Yes, I did see that, and while i admired the hack, it wont work in our
> situation. :)
>
> I'd really like to see this very old bug fixed.
>
> If for no other reason, it was stated it would work, and does not.
>
> -Matthew
>
its a big change. fix for 3.3 ? This would seriously nuke loadbalancing
for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable
out after so many months (years?).
-Ys-
yhs@mimic.onesourcecorp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: No revolution today
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Thu, 9 Nov 2000, Matthew Dornquast wrote:
> re>Our site (http://www.spun.com) runs multiple Apache servers with load
> balancers ("rotator box like BigIP") that distribute traffic over the Apache
> servers. We have a farm of Tomcat servers. The session API's work for us.
> The only problem is that Tomcat, as distributed, does not allow load
> balancing persistence for the root context. We hacked a way around that
> (search the archives if you're interested) - but it's an admitted kludge.
> --------------
>
> Yes, I did see that, and while i admired the hack, it wont work in our
> situation. :)
>
> I'd really like to see this very old bug fixed.
>
> If for no other reason, it was stated it would work, and does not.
>
> -Matthew
>
its a big change. fix for 3.3 ? This would seriously nuke loadbalancing
for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable
out after so many months (years?).
-Ys-
yhs@mimic.onesourcecorp.com
Re: No revolution today
Posted by Matthew Dornquast <ma...@webhelp.com>.
re>Our site (http://www.spun.com) runs multiple Apache servers with load
balancers ("rotator box like BigIP") that distribute traffic over the Apache
servers. We have a farm of Tomcat servers. The session API's work for us.
The only problem is that Tomcat, as distributed, does not allow load
balancing persistence for the root context. We hacked a way around that
(search the archives if you're interested) - but it's an admitted kludge.
--------------
Yes, I did see that, and while i admired the hack, it wont work in our
situation. :)
I'd really like to see this very old bug fixed.
If for no other reason, it was stated it would work, and does not.
-Matthew
RE: No revolution today
Posted by Joseph Chiu <jc...@spun.com>.
Our site (http://www.spun.com) runs multiple Apache servers with load
balancers ("rotator box like BigIP") that distribute traffic over the Apache
servers. We have a farm of Tomcat servers. The session API's work for us.
The only problem is that Tomcat, as distributed, does not allow load
balancing persistence for the root context. We hacked a way around that
(search the archives if you're interested) - but it's an admitted kludge.
Joseph
-----Original Message-----
From: Nick Bauman [mailto:nick@cortexity.com]
Sent: Wednesday, November 08, 2000 8:42 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: No revolution today
On Thu, 9 Nov 2000, Henri Gomez wrote:
> > It is important that tomcat3 has a design that allows support for
> > future
> > versions of the servlet API, but if tomcat developers don't want to see
> > it
> > happen - so be it. When Servlet2.3 will be final and in wide use, there
> > is
> > nothing that can stop someone from providing the module that supports it
> > (
> > not necesarily from apache site ).
>
> Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for
at
> least one or two years. Note that many importants sites still use Apache
JServ
> (API 2.0) and GnuJSP.
>
I for one, would love to see the 3.x codebase's Session API actually work
"as advertised" in a web server farm with a rotator box like BigIP. Right
now the Session API in tomcat 3.1 /does not work/ across multiple
instances of tomcat in a server farm.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: No revolution today
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Thu, 9 Nov 2000, Matthew Dornquast wrote:
> > umm...it does. i use it.
> > -Ys-
>
> My understanding is it DOES work for app contexts mapped to a URL like
> "/myapp" but it does NOT work
> for the root context. "/"
>
> Many of us have webapps that mount to the root context.
>
> I spent WAY to much time figuring this out, I'd love to be proven wrong.
> But the mailing list supports what I'm saying if you search for "load
> balancing"
>
> -Matthew
>
yep. root context bug. reported loong ago.
-Ys-
yhs@mimic.onesourcecorp.com
Re: No revolution today
Posted by Matthew Dornquast <ma...@webhelp.com>.
> umm...it does. i use it.
> -Ys-
My understanding is it DOES work for app contexts mapped to a URL like
"/myapp" but it does NOT work
for the root context. "/"
Many of us have webapps that mount to the root context.
I spent WAY to much time figuring this out, I'd love to be proven wrong.
But the mailing list supports what I'm saying if you search for "load
balancing"
-Matthew
Re: No revolution today
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Thu, 9 Nov 2000, Nick Bauman wrote:
>
> How? As far as I can tell it's broken in TC 3.1 / mod_jserv. Can you
> describe your configuration?
>
><SNIP>
> > > "as advertised" in a web server farm with a rotator box like BigIP. Right
> > > now the Session API in tomcat 3.1 /does not work/ across multiple
> > > instances of tomcat in a server farm.
> > >
> > >
> >
> > umm...it does. i use it.
> > -Ys-
> > yhs@mimic.onesourcecorp.com
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
> --
> Nicolaus Bauman
> Software Engineer
> Simplexity Systems
>
__ 4 x
/- 3 x -----/-- tomcat JVMs
Net---Load Balancer-------- apache \-per apachewebserver.
(piranha - redhat) \- web servers
with mod_jserv x 3
i also use :
Net-------------------Apache with mod_jserv ----< 30 x tomcat jvms.
-Ys-
yhs@mimic.onesourcecorp.com
Re: No revolution today
Posted by Nick Bauman <ni...@cortexity.com>.
How? As far as I can tell it's broken in TC 3.1 / mod_jserv. Can you
describe your configuration?
On Thu, 9 Nov 2000, yhs@mimic.onesourcecorp.com wrote:
>
>
> On Wed, 8 Nov 2000, Nick Bauman wrote:
>
> > On Thu, 9 Nov 2000, Henri Gomez wrote:
> >
> > > > It is important that tomcat3 has a design that allows support for
> > > > future
> > > > versions of the servlet API, but if tomcat developers don't want to see
> > > > it
> > > > happen - so be it. When Servlet2.3 will be final and in wide use, there
> > > > is
> > > > nothing that can stop someone from providing the module that supports it
> > > > (
> > > > not necesarily from apache site ).
> > >
> > > Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at
> > > least one or two years. Note that many importants sites still use Apache JServ
> > > (API 2.0) and GnuJSP.
> > >
> >
> > I for one, would love to see the 3.x codebase's Session API actually work
> > "as advertised" in a web server farm with a rotator box like BigIP. Right
> > now the Session API in tomcat 3.1 /does not work/ across multiple
> > instances of tomcat in a server farm.
> >
> >
>
> umm...it does. i use it.
> -Ys-
> yhs@mimic.onesourcecorp.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
Re: No revolution today
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Wed, 8 Nov 2000, Nick Bauman wrote:
> On Thu, 9 Nov 2000, Henri Gomez wrote:
>
> > > It is important that tomcat3 has a design that allows support for
> > > future
> > > versions of the servlet API, but if tomcat developers don't want to see
> > > it
> > > happen - so be it. When Servlet2.3 will be final and in wide use, there
> > > is
> > > nothing that can stop someone from providing the module that supports it
> > > (
> > > not necesarily from apache site ).
> >
> > Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at
> > least one or two years. Note that many importants sites still use Apache JServ
> > (API 2.0) and GnuJSP.
> >
>
> I for one, would love to see the 3.x codebase's Session API actually work
> "as advertised" in a web server farm with a rotator box like BigIP. Right
> now the Session API in tomcat 3.1 /does not work/ across multiple
> instances of tomcat in a server farm.
>
>
umm...it does. i use it.
-Ys-
yhs@mimic.onesourcecorp.com
RE: No revolution today
Posted by Laurent Salle <La...@aventin.com>.
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: Thursday, November 09, 2000 5:42 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: No revolution today
>
>
> On Thu, 9 Nov 2000, Henri Gomez wrote:
>
> > > It is important that tomcat3 has a design that allows support for
> > > future
> > > versions of the servlet API, but if tomcat developers don't
> want to see
> > > it
> > > happen - so be it. When Servlet2.3 will be final and in wide
> use, there
> > > is
> > > nothing that can stop someone from providing the module that
> supports it
> > > (
> > > not necesarily from apache site ).
> >
> > Many of us could live with a bullet proof TC 3.3 with API
> 2.2/JSP 1.1 for at
> > least one or two years. Note that many importants sites still
> use Apache JServ
> > (API 2.0) and GnuJSP.
> >
>
> I for one, would love to see the 3.x codebase's Session API actually work
> "as advertised" in a web server farm with a rotator box like BigIP. Right
> now the Session API in tomcat 3.1 /does not work/ across multiple
> instances of tomcat in a server farm.
>
I just read the BigIP specification.
http://www.f5.com/bigip/
and I expect that Tomcat is working in the cookie passive mode of
persistence
Is-it right ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: No revolution today
Posted by cm...@yahoo.com.
>
> I for one, would love to see the 3.x codebase's Session API actually work
> "as advertised" in a web server farm with a rotator box like BigIP. Right
> now the Session API in tomcat 3.1 /does not work/ across multiple
> instances of tomcat in a server farm.
And that's why the session stuff is almost completely separated from the
core, in a separate package and with only minor dependencies.
Even more, a new session manager can be created in an independent module (
like a revolution ) - that can be shared with other containers ( even if I
know some that don't like to share :-).
In fact, most of the session management can be implemented in "user
space", with only minor things in the core ( allowing maximum flexibility
for the user - since he would just use a library, with an unlimited API,
not only the few methods provided by Servlet2.2 ).
I don't think I'll be able to do that very soon, but if anyone wants to
start it I would certainly help as much as possible.
There are few (major) optimizations that needs to be done in session
management, but I think Parameters and Dispatcher are more urgent.
Costin
Re: No revolution today
Posted by Nick Bauman <ni...@cortexity.com>.
On Thu, 9 Nov 2000, Henri Gomez wrote:
> > It is important that tomcat3 has a design that allows support for
> > future
> > versions of the servlet API, but if tomcat developers don't want to see
> > it
> > happen - so be it. When Servlet2.3 will be final and in wide use, there
> > is
> > nothing that can stop someone from providing the module that supports it
> > (
> > not necesarily from apache site ).
>
> Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at
> least one or two years. Note that many importants sites still use Apache JServ
> (API 2.0) and GnuJSP.
>
I for one, would love to see the 3.x codebase's Session API actually work
"as advertised" in a web server farm with a rotator box like BigIP. Right
now the Session API in tomcat 3.1 /does not work/ across multiple
instances of tomcat in a server farm.
Re: No revolution today
Posted by Henri Gomez <hg...@slib.fr>.
> It is important that tomcat3 has a design that allows support for
> future
> versions of the servlet API, but if tomcat developers don't want to see
> it
> happen - so be it. When Servlet2.3 will be final and in wide use, there
> is
> nothing that can stop someone from providing the module that supports it
> (
> not necesarily from apache site ).
Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at
least one or two years. Note that many importants sites still use Apache JServ
(API 2.0) and GnuJSP.
> But for now it's important to continue to improve the foundation.
>
>
> My focus will continue to be on Tomcat3.3, in fixing the encoding
> problems and on improving the performance. We are not yet the best
> servlet container - so there is still work to do.
> If you believe that tomcat3 can't be the best container, and a
> different
> model is better suited for that - that's perfect, as long as the code
> you
> write is reusable everyone will benefit. And I'm sure the users will
> choose whatever it's better for them, regardless of version
> numbers. It's open source - and so far the better code has survived
> regardless of politics.
Yes, TC 3.3 must fix TC 3.2 bugs and boost performances. Users could allways
bench TC 3.3 vs TC 4.0 or others servlets engines. And they'll choose their
favorite
> The rules are still there - after a release, the main branch is open
> for
> the development of the next release, and as long as we are improving I
> don't think anyone can stop the evolution.
RE: Scalability and revolution?
Posted by Paulo Gaspar <pa...@krankikom.de>.
Sorry Roy.
Scability is not much of a problem here.
With the framework I built, using JServ as Web Server, Oracle 8i as
database and JDK 1.3 (w/ Hotspot) we can serve over 30 hits per
second on the most typical dynamic pages in current (800 MHz) CPUs
and enough memory (and the thing has templates, yes... just not XSL
ones).
30 hits per second on dynamic pages is a lot, especially when most of
the pages accessed are still static. It is going to take some time
before we need to think about multiple servers.
And then, since the user validation is done on Apache, I suspect I
can work around session management in my framework while using a
single Apache server to distribute requests to several JServ/Tomcat
Servlet engines - the user will not have to login more than once
and I will work on a user basis instead of on a session basis.
(Good enough for my situation... maybe not for yours.)
Of course that I hope to have other solutions when I get there.
Still, if one is able to make his/hers code fast enough, multiple
server solutions are not such a common problem. Only a megasite
problem.
>30 hits per second just for dynamic pages is a lot, and it is
not hard to achieve with current hardware.
Have fun,
Paulo
-----Original Message-----
From: Roy Wilson [mailto:designrw@bellatlantic.net]
Sent: Thursday, November 09, 2000 19:14
Paulo,
I wonder whether, and in what way you address the scalability of a
production site. In particular, do you purchase a machine or select an
app based on an estimate of its scalability?
Roy
--
Roy Wilson
E-mail: designrw@bellatlantic.net
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 11/9/00, 9:27:19 AM, "Paulo Gaspar" <pa...@krankikom.de>
wrote regarding RE: No revolution today:
> Very wise decision.
> And nothing forbids you of doing those revolutions in the future.
> But at the moment, for me, my company and people/companies I know,
the ONE
> main priority is having a fast and robust Servlet Engine - with
robust
> being the priority.
> Your focus on a modular architecture keeps all doors open for the
> development of new features. IMO, a robust, fast enough and easily
> extensible Servlet Engine would take the market.
> We do NOT necessarily depend on a engine that is the "reference
> implementation of..." and that has hundreds of features.
> We depend on a engine we can use on production sites.
> Have fun,
> Paulo
Scalability and revolution?
Posted by Roy Wilson <de...@bellatlantic.net>.
Paulo,
I wonder whether, and in what way you address the scalability of a
production site. In particular, do you purchase a machine or select an
app based on an estimate of its scalability?
Roy
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 11/9/00, 9:27:19 AM, "Paulo Gaspar" <pa...@krankikom.de> wrote
regarding RE: No revolution today:
> Very wise decision.
> And nothing forbids you of doing those revolutions in the future.
> But at the moment, for me, my company and people/companies I know, the
ONE
> main priority is having a fast and robust Servlet Engine - with robust
> being the priority.
> Your focus on a modular architecture keeps all doors open for the
> development of new features. IMO, a robust, fast enough and easily
> extensible Servlet Engine would take the market.
> We do NOT necessarily depend on a engine that is the "reference
> implementation of..." and that has hundreds of features.
> We depend on a engine we can use on production sites.
> Have fun,
> Paulo
> > -----Original Message-----
> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > Sent: Wednesday, November 08, 2000 19:56
> >
> >
> > Hi,
> >
> > After a lot of thinking, I decided to give up ( at least temporary ) my
> > plans for a tomcat revolution. It was very tempting, but I don't think
> > it's the right thing to do - evolution is still the best way to go :-)
> >
> >
> > It is important that tomcat3 has a design that allows support for future
> > versions of the servlet API, but if tomcat developers don't want to see
it
> > happen - so be it. When Servlet2.3 will be final and in wide use, there
is
> > nothing that can stop someone from providing the module that supports it
(
> > not necesarily from apache site ).
> >
> >
> > But for now it's important to continue to improve the foundation.
> >
> >
> > My focus will continue to be on Tomcat3.3, in fixing the encoding
> > problems and on improving the performance. We are not yet the best
> > servlet container - so there is still work to do.
> >
> >
> ....
> >
> > Costin
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: No revolution today
Posted by Henri Gomez <hg...@slib.fr>.
En réponse à Paulo Gaspar <pa...@krankikom.de>:
> But at the moment, for me, my company and people/companies I know, the
> ONE
> main priority is having a fast and robust Servlet Engine - with robust
> being the priority.
+1
> Your focus on a modular architecture keeps all doors open for the
> development of new features. IMO, a robust, fast enough and easily
> extensible Servlet Engine would take the market.
+2
> We do NOT necessarily depend on a engine that is the "reference
> implementation of..." and that has hundreds of features.
>
> We depend on a engine we can use on production sites.
+3
PS: I'd like to see that I'm not the only one worried about quality and
production use ;-$
RE: No revolution today
Posted by Paulo Gaspar <pa...@krankikom.de>.
Very wise decision.
And nothing forbids you of doing those revolutions in the future.
But at the moment, for me, my company and people/companies I know, the ONE
main priority is having a fast and robust Servlet Engine - with robust
being the priority.
Your focus on a modular architecture keeps all doors open for the
development of new features. IMO, a robust, fast enough and easily
extensible Servlet Engine would take the market.
We do NOT necessarily depend on a engine that is the "reference
implementation of..." and that has hundreds of features.
We depend on a engine we can use on production sites.
Have fun,
Paulo
> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Wednesday, November 08, 2000 19:56
>
>
> Hi,
>
> After a lot of thinking, I decided to give up ( at least temporary ) my
> plans for a tomcat revolution. It was very tempting, but I don't think
> it's the right thing to do - evolution is still the best way to go :-)
>
>
> It is important that tomcat3 has a design that allows support for future
> versions of the servlet API, but if tomcat developers don't want to see it
> happen - so be it. When Servlet2.3 will be final and in wide use, there is
> nothing that can stop someone from providing the module that supports it (
> not necesarily from apache site ).
>
>
> But for now it's important to continue to improve the foundation.
>
>
> My focus will continue to be on Tomcat3.3, in fixing the encoding
> problems and on improving the performance. We are not yet the best
> servlet container - so there is still work to do.
>
>
....
>
> Costin
>