You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@covalent.net on 2002/06/24 19:22:03 UTC
5.0 proposal
It seems we have 3 -1 votes so far. While majority is required, I think
we all agree that getting everyone ( reasonable ) involved and comfortable
with the proposal is very important ( and one of the goals of 5.0 ).
Christopher: I think we should add your requirement for performance
testing to the proposal. In fact, we should add a whole section about
testing for 5.0. Would this satisfy you ?
Glenn - I'm not sure what you ask for. The proposal adds no new
features (except the new servlet api), and we obviously can't
implement the next spec unless it's public. I understand your concern
about the time - but given that the code will be shared ( i.e. existing
code ) I don't think it should take years to get it done. Is there
any particular requirement you want to add to the proposal ?
For everyone - the proposal is in CVS, and everyone can contribute
to it. One of the main goals is to improve the community, and that
means we should be more sensitive to other needs. If you have an itch,
please add it to the plan, as a goal for 5.0 ( some may not happen
in 5.0.0 ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by co...@covalent.net.
On Mon, 24 Jun 2002, Glenn Nielsen wrote:
> +1 to add a Tomcat specific performance testing/benchmark repository.
>
> Perhaps it would be best if it were in its own repository,
> jakarta-tomcat-benchmark ? I will help as I have time.
I think we have 3 +1s and one -1 - maybe Remy can change his vote ?
I don't thing j-t-benchmark is a good idea ( see later ), it should
be in the same place with the tests ( and the total time to run
the watchdog or product tests is a benchmark by itself )
> The latest Tomcat 5 proposal looks much better. I am still -1 for
> starting the work until the JCP releases JSR 152 and JSR 154 for
> public review.
If you are talking about the implementation of the servlet/jsp
part - I totally agree, it would be pretty hard to implement it
without reading it first :-)
The JSP2.0 PD seems to be out ( and much larger than the previous,
it'll take few days to read it - I'm afraid we'll have a bloat fest..).
Regarding the other enhancements to Coyote and other parts -
I think we can start planning and discussing, that will take
some time.
Most of the work for 5.0 will actually be the same as work for 4.1 - so
we are in effect working on it already.
> There is one addition to the proposal I think we should discuss at
> this time. That is the organization of the CVS repostories for
> Tomcat.
Yes, that's a big pain for me too.
> The trend started a while ago was to break out common components into
> their own repository. jakarta-tomcat-connectors and
> jakarta-tomcat-jasper for example.
>
> Perhaps this would be the time to consider if there are better ways
> to organize the code. The reorganization would have three goals:
>
> 1. Allow sharing of components between different versions of Tomcat
>
> 2. Reduce duplication and maintenance of code in multiple branches of
> one CVS repository.
>
> 3. Make the code base in each repository more tightly focused on
> what it does, thus making it easier for developers to find bugs
> and submit patches.
>
> As an example, there are now at least 4 different versions of jasper
> in various repositories.
>
> jakarta-tomcat-jasper/jasper34
> jakarta-tomcat-jasper/jasper2
> jakarta-tomcat/jasper
> jakarta-tomcat-4.0/jasper
>
> Tomcat 5 would add a fifth.
>
> There are many other things that would be in common between Tomcat 4
> and Tomcat 5 which are not dependent on the Servlet or JSP version.
> Moving these out of the core Tomcat CVS repositories would make life
> easier.
>
> Thoughts?
+1, but I don't like creating too many CVS repositories, and
I don't think we should create too many big disruptions.
What about a jakarta-tomcat-modules/ CVS repository, with a structure
similar with commons or taglibs ?
All new components will go there - and eventually we can migrate
any old component that gets refactored and we make the code more
modular.
I think we should keep j-t-c and j-t-j, those are pretty big chunks.
Eventually j-t-5.0 should only contain the servlet implementation,
with no module, coyote will be in j-t-c - and all other modules
in j-t-m.
( well, that's a quick proposal - I'm not very sure it is good )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: 5.0 proposal
Posted by Kevin Jones <ke...@develop.com>.
FYI
JSR 152 is now in PFD
http://jcp.org/aboutJava/communityprocess/review/jsr152/index.html
Kevin Jones
Developmentor
www.develop.com
> -----Original Message-----
> From: glenn@zathras.earthdome.org
> [mailto:glenn@zathras.earthdome.org] On Behalf Of Glenn Nielsen
> Sent: 25 June 2002 05:34
> To: Tomcat Developers List
> Subject: Re: 5.0 proposal
>
>
> Remy Maucherat wrote:
> >
> > costinm@covalent.net wrote:
> > > It seems we have 3 -1 votes so far. While majority is required, I
> > > think we all agree that getting everyone ( reasonable )
> involved and
> > > comfortable with the proposal is very important ( and one of the
> > > goals of 5.0 ).
> >
> > +1.
> >
> > > Christopher: I think we should add your requirement for
> performance
> > > testing to the proposal. In fact, we should add a whole section
> > > about testing for 5.0. Would this satisfy you ?
> >
> > +1 to start a new commons subproject.
> > If everyone else wants to see the bench webapp here, then
> I'll remove
> > my -1. However, it sounds generic, and not at all dependent
> on Tomcat,
> > so that's why I think it would be a lot better in the commons.
> >
>
> +1 to add a Tomcat specific performance testing/benchmark repository.
>
> Perhaps it would be best if it were in its own repository,
> jakarta-tomcat-benchmark ? I will help as I have time.
>
> > > Glenn - I'm not sure what you ask for. The proposal adds no new
> > > features (except the new servlet api), and we obviously can't
> > > implement the next spec unless it's public. I understand your
> > > concern about the time - but given that the code will be shared (
> > > i.e. existing code ) I don't think it should take years to get it
> > > done. Is there any particular requirement you want to add to the
> > > proposal ?
> >
> > I added some details about the changes.
> >
> > > For everyone - the proposal is in CVS, and everyone can
> contribute
> > > to it. One of the main goals is to improve the community,
> and that
> > > means we should be more sensitive to other needs. If you have an
> > > itch, please add it to the plan, as a goal for 5.0 ( some may not
> > > happen in 5.0.0 ).
> >
> > Not many of the negative comments posted actually contained any
> > suggestions, so I didn't see much worth integrating, except Glenn's
> > comments about lack of detail.
> >
>
> The latest Tomcat 5 proposal looks much better. I am still
> -1 for starting the work until the JCP releases JSR 152 and
> JSR 154 for public review.
>
> There is one addition to the proposal I think we should
> discuss at this time. That is the organization of the CVS
> repostories for Tomcat.
>
> The trend started a while ago was to break out common
> components into their own repository.
> jakarta-tomcat-connectors and jakarta-tomcat-jasper for example.
>
> Perhaps this would be the time to consider if there are
> better ways to organize the code. The reorganization would
> have three goals:
>
> 1. Allow sharing of components between different versions of Tomcat
>
> 2. Reduce duplication and maintenance of code in multiple branches of
> one CVS repository.
>
> 3. Make the code base in each repository more tightly focused on
> what it does, thus making it easier for developers to find bugs
> and submit patches.
>
> As an example, there are now at least 4 different versions of
> jasper in various repositories.
>
> jakarta-tomcat-jasper/jasper34
> jakarta-tomcat-jasper/jasper2
> jakarta-tomcat/jasper
> jakarta-tomcat-4.0/jasper
>
> Tomcat 5 would add a fifth.
>
> There are many other things that would be in common between
> Tomcat 4 and Tomcat 5 which are not dependent on the Servlet
> or JSP version. Moving these out of the core Tomcat CVS
> repositories would make life easier.
>
> Thoughts?
>
>
> Regards,
>
> Glenn
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Remy Maucherat wrote:
>
> costinm@covalent.net wrote:
> > It seems we have 3 -1 votes so far. While majority is required, I think
> > we all agree that getting everyone ( reasonable ) involved and comfortable
> > with the proposal is very important ( and one of the goals of 5.0 ).
>
> +1.
>
> > Christopher: I think we should add your requirement for performance
> > testing to the proposal. In fact, we should add a whole section about
> > testing for 5.0. Would this satisfy you ?
>
> +1 to start a new commons subproject.
> If everyone else wants to see the bench webapp here, then I'll remove my
> -1. However, it sounds generic, and not at all dependent on Tomcat, so
> that's why I think it would be a lot better in the commons.
>
+1 to add a Tomcat specific performance testing/benchmark repository.
Perhaps it would be best if it were in its own repository,
jakarta-tomcat-benchmark ? I will help as I have time.
> > Glenn - I'm not sure what you ask for. The proposal adds no new
> > features (except the new servlet api), and we obviously can't
> > implement the next spec unless it's public. I understand your concern
> > about the time - but given that the code will be shared ( i.e. existing
> > code ) I don't think it should take years to get it done. Is there
> > any particular requirement you want to add to the proposal ?
>
> I added some details about the changes.
>
> > For everyone - the proposal is in CVS, and everyone can contribute
> > to it. One of the main goals is to improve the community, and that
> > means we should be more sensitive to other needs. If you have an itch,
> > please add it to the plan, as a goal for 5.0 ( some may not happen
> > in 5.0.0 ).
>
> Not many of the negative comments posted actually contained any
> suggestions, so I didn't see much worth integrating, except Glenn's
> comments about lack of detail.
>
The latest Tomcat 5 proposal looks much better. I am still -1 for
starting the work until the JCP releases JSR 152 and JSR 154 for
public review.
There is one addition to the proposal I think we should discuss at
this time. That is the organization of the CVS repostories for
Tomcat.
The trend started a while ago was to break out common components into their own repository. jakarta-tomcat-connectors and jakarta-tomcat-jasper for example.
Perhaps this would be the time to consider if there are better ways
to organize the code. The reorganization would have three goals:
1. Allow sharing of components between different versions of Tomcat
2. Reduce duplication and maintenance of code in multiple branches of
one CVS repository.
3. Make the code base in each repository more tightly focused on
what it does, thus making it easier for developers to find bugs
and submit patches.
As an example, there are now at least 4 different versions of jasper
in various repositories.
jakarta-tomcat-jasper/jasper34
jakarta-tomcat-jasper/jasper2
jakarta-tomcat/jasper
jakarta-tomcat-4.0/jasper
Tomcat 5 would add a fifth.
There are many other things that would be in common between Tomcat 4
and Tomcat 5 which are not dependent on the Servlet or JSP version.
Moving these out of the core Tomcat CVS repositories would make life
easier.
Thoughts?
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Remy Maucherat wrote:
> costinm@covalent.net wrote:
>
>> It seems we have 3 -1 votes so far. While majority is required, I think
>> we all agree that getting everyone ( reasonable ) involved and
>> comfortable
>> with the proposal is very important ( and one of the goals of 5.0 ).
>
>
> +1.
>
>> Christopher: I think we should add your requirement for performance
>> testing to the proposal. In fact, we should add a whole section about
>> testing for 5.0. Would this satisfy you ?
>
>
> +1 to start a new commons subproject.
How about making it part of JMeter?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by co...@covalent.net.
On Mon, 24 Jun 2002, Remy Maucherat wrote:
> +1 to start a new commons subproject.
> If everyone else wants to see the bench webapp here, then I'll remove my
> -1. However, it sounds generic, and not at all dependent on Tomcat, so
> that's why I think it would be a lot better in the commons.
Maybe watchdog would be a better place for it ( or a -tomcat repository
for all tests ) ?
Fact is testing tomcat is important and performance is one of the
test categories.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Remy Maucherat <re...@apache.org>.
costinm@covalent.net wrote:
> It seems we have 3 -1 votes so far. While majority is required, I think
> we all agree that getting everyone ( reasonable ) involved and comfortable
> with the proposal is very important ( and one of the goals of 5.0 ).
+1.
> Christopher: I think we should add your requirement for performance
> testing to the proposal. In fact, we should add a whole section about
> testing for 5.0. Would this satisfy you ?
+1 to start a new commons subproject.
If everyone else wants to see the bench webapp here, then I'll remove my
-1. However, it sounds generic, and not at all dependent on Tomcat, so
that's why I think it would be a lot better in the commons.
> Glenn - I'm not sure what you ask for. The proposal adds no new
> features (except the new servlet api), and we obviously can't
> implement the next spec unless it's public. I understand your concern
> about the time - but given that the code will be shared ( i.e. existing
> code ) I don't think it should take years to get it done. Is there
> any particular requirement you want to add to the proposal ?
I added some details about the changes.
> For everyone - the proposal is in CVS, and everyone can contribute
> to it. One of the main goals is to improve the community, and that
> means we should be more sensitive to other needs. If you have an itch,
> please add it to the plan, as a goal for 5.0 ( some may not happen
> in 5.0.0 ).
Not many of the negative comments posted actually contained any
suggestions, so I didn't see much worth integrating, except Glenn's
comments about lack of detail.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Anyone know a way around this
Posted by John Trollinger <ja...@trollingers.com>.
Generated servlet error:
C:\WEBCTRL2_0\jspcache\testsystem\properties\lvl5\huge$jsp.java:30165:
code too large for try statement
} catch (Throwable t) {
^
C:\WEBCTRL2_0\jspcache\testsystem\properties\lvl5\huge$jsp.java:2969:
code too large for try statement
try {
^
An error occurred at line: 102 in the jsp file:
/testsystem/properties/lvl5/huge.staging.jsp
Generated servlet error:
Note: C:\WEBCTRL2_0\jspcache\testsystem\properties\lvl5\huge$jsp.java
uses or overrides a deprecated API.
Note: Recompile with -deprecation for details.
2 errors
Compile failed; see the compiler error output for details.
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:274)
at
org.apache.jasper.JspEngineContext.compile(JspEngineContext.java:385)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:157)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:287)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:215)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator
Base.java:472)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
va:246)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:236
6)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:163)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
ava:1005)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
1098)
at java.lang.Thread.run(Thread.java:479)
at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHa
ndler.java:120)
at
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.ja
va:293)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:291)
at
org.apache.jasper.JspEngineContext.compile(JspEngineContext.java:385)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:157)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:287)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:215)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator
Base.java:472)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
va:246)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:236
6)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:163)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
ava:1005)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
1098)
at java.lang.Thread.run(Thread.java:479)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, June 25, 2002 3:36 PM
Subject: Re: 5.0 proposal
> Arshad Mahmood <ar...@compuvision.co.uk> wrote:
>
> > +100!
> >
> > As somebody who also intends to use Tomcat in production (around 10
> > different sites with a reasonable load, maybe 1/4 of vnunet) this would
be
> > very helpful to me.
> >
> > You mentioned a couple of specific things you would like to do. Would it
be
> > possible for you elaborate a little more.
>
> Arshad, you don't count... You work with me! :) :) :) :)
Pier,
This is for my own sites not for vnu (my commitments are very limited to vnu
anyway). I intend to go with Tomcat 4.1 into production in the next couple
of weeks (volume will be insignificant for the first site) so I intend to
spend quite a bit of time trying to iron out bugs/problems and scaling
issues.
As such I have the time to spare to work on the Tomcat enhancements to make
it more scalable/reliable. I am very keen to hear your ideas.
Regards,
Arshad
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Pier Fumagalli <pi...@betaversion.org>.
Arshad Mahmood <ar...@compuvision.co.uk> wrote:
> +100!
>
> As somebody who also intends to use Tomcat in production (around 10
> different sites with a reasonable load, maybe 1/4 of vnunet) this would be
> very helpful to me.
>
> You mentioned a couple of specific things you would like to do. Would it be
> possible for you elaborate a little more.
Arshad, you don't count... You work with me! :) :) :) :)
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: 5.0 proposal
Posted by Steven Wood <st...@all-hotels.com>.
>> I am really sorry, but you have only yourself to blame for not at least
upgrading to Tomcat 3.3.x, which is the HA version of Tomcat 3.2.
yip, I know, i'm dowloading it as i send this :-)
-----Original Message-----
From: Remy Maucherat [mailto:remm@apache.org]
Sent: 25 June 2002 09:45
To: Tomcat Developers List
Subject: Re: 5.0 proposal
Steven Wood wrote:
> Hi all,
>
> I was interested to read the differing opinions on 5.0 or not, and I was
> interested to hear Pier say that he did not think tomcat was an option in
a
> production system. We have been using tomcat 3.2.3 (an out of date
version
> I know) and while it performs it very well under a light load, some
strange
> things start to happen when our site gets busy the only solution seems to
be
> to shut down and restart tomcat (I know that this it not supposed to
> required on a regular basis is it ?). I wont bother describing exactly
what
> happens because we are using an older version and some of the issues may
> have been resolved, but we do get some unexpected behaviour under high
> loads.
I am really sorry, but you have only yourself to blame for not at least
upgrading to Tomcat 3.3.x, which is the HA version of Tomcat 3.2.
> Long and short : as a user of tomcat, i would be far more appreciative of
a
> so called "high-availability or hard-edition" than an new "feature rich"
> version. Just because thats of most use (I think) to me though :-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
__________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service.
For more information, visit http://www.messagelabs.com
_____________________________________________________________________
This message from All-Hotels has been checked for all known viruses
by the MessageLabs Virus Scanning Service. For further information visit:
http://www.messagelabs.com/stats.asp
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Remy Maucherat <re...@apache.org>.
Steven Wood wrote:
> Hi all,
>
> I was interested to read the differing opinions on 5.0 or not, and I was
> interested to hear Pier say that he did not think tomcat was an option in a
> production system. We have been using tomcat 3.2.3 (an out of date version
> I know) and while it performs it very well under a light load, some strange
> things start to happen when our site gets busy the only solution seems to be
> to shut down and restart tomcat (I know that this it not supposed to
> required on a regular basis is it ?). I wont bother describing exactly what
> happens because we are using an older version and some of the issues may
> have been resolved, but we do get some unexpected behaviour under high
> loads.
I am really sorry, but you have only yourself to blame for not at least
upgrading to Tomcat 3.3.x, which is the HA version of Tomcat 3.2.
> Long and short : as a user of tomcat, i would be far more appreciative of a
> so called "high-availability or hard-edition" than an new "feature rich"
> version. Just because thats of most use (I think) to me though :-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: 5.0 proposal
Posted by Steven Wood <st...@all-hotels.com>.
Hi all,
I was interested to read the differing opinions on 5.0 or not, and I was
interested to hear Pier say that he did not think tomcat was an option in a
production system. We have been using tomcat 3.2.3 (an out of date version
I know) and while it performs it very well under a light load, some strange
things start to happen when our site gets busy the only solution seems to be
to shut down and restart tomcat (I know that this it not supposed to
required on a regular basis is it ?). I wont bother describing exactly what
happens because we are using an older version and some of the issues may
have been resolved, but we do get some unexpected behaviour under high
loads.
Long and short : as a user of tomcat, i would be far more appreciative of a
so called "high-availability or hard-edition" than an new "feature rich"
version. Just because thats of most use (I think) to me though :-)
-----Original Message-----
From: Arshad Mahmood [mailto:arshadm@compuvision.co.uk]
Sent: 25 June 2002 09:12
To: Tomcat Developers List
Subject: Re: 5.0 proposal
----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, June 24, 2002 9:49 PM
Subject: Re: 5.0 proposal
> costinm@covalent.net <co...@covalent.net> wrote:
>
> > On Mon, 24 Jun 2002, Pier Fumagalli wrote:
> >
> >> That's why counts where not right on my side of the border... I don't
recall
> >> vetoing the proposal... I just complained vehemently that I'd prefer to
see
> >> 4.0 out of the door and stable rather than a 4.1 and a 5.0...
> >
> > 4.0 is out of door - the release happened long ago. So did 4.0.1...
4.0.4.
> >
> > 4.1 is getting close - and it should be more stable and better than
4.0.4.
> > And 5.0 should be more stable and better than 4.1 and 3.3.
> >
> > And 6.0 will probably be better than 5.0.
> >
> > If you are interested in maintaining and improving 4.0.4 - just
volunteer
> > as release manager for the branch, you have my +1 on it.
>
> I can't be a RM for 4.0.4 because I would simply remove 70% of the code,
and
> kiddies would start crying their butts off because they don't have the
> manager application, or JSP support :)
>
> But if anyone is interested I'd like to explore the opportunity of a
> Tomcat-HA (high-availability or hard-edition), based on 4.0 without the
> "crap" in there, and straightening out the request-response model...
+100!
As somebody who also intends to use Tomcat in production (around 10
different sites with a reasonable load, maybe 1/4 of vnunet) this would be
very helpful to me.
You mentioned a couple of specific things you would like to do. Would it be
possible for you elaborate a little more.
Regards,
Arshad
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
__________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service.
For more information, visit http://www.messagelabs.com
_____________________________________________________________________
This message from All-Hotels has been checked for all known viruses
by the MessageLabs Virus Scanning Service. For further information visit:
http://www.messagelabs.com/stats.asp
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Arshad Mahmood <ar...@compuvision.co.uk>.
----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, June 24, 2002 9:49 PM
Subject: Re: 5.0 proposal
> costinm@covalent.net <co...@covalent.net> wrote:
>
> > On Mon, 24 Jun 2002, Pier Fumagalli wrote:
> >
> >> That's why counts where not right on my side of the border... I don't
recall
> >> vetoing the proposal... I just complained vehemently that I'd prefer to
see
> >> 4.0 out of the door and stable rather than a 4.1 and a 5.0...
> >
> > 4.0 is out of door - the release happened long ago. So did 4.0.1...
4.0.4.
> >
> > 4.1 is getting close - and it should be more stable and better than
4.0.4.
> > And 5.0 should be more stable and better than 4.1 and 3.3.
> >
> > And 6.0 will probably be better than 5.0.
> >
> > If you are interested in maintaining and improving 4.0.4 - just
volunteer
> > as release manager for the branch, you have my +1 on it.
>
> I can't be a RM for 4.0.4 because I would simply remove 70% of the code,
and
> kiddies would start crying their butts off because they don't have the
> manager application, or JSP support :)
>
> But if anyone is interested I'd like to explore the opportunity of a
> Tomcat-HA (high-availability or hard-edition), based on 4.0 without the
> "crap" in there, and straightening out the request-response model...
+100!
As somebody who also intends to use Tomcat in production (around 10
different sites with a reasonable load, maybe 1/4 of vnunet) this would be
very helpful to me.
You mentioned a couple of specific things you would like to do. Would it be
possible for you elaborate a little more.
Regards,
Arshad
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: random BOUND socket (was Re: 5.0 proposal).
Posted by Pier Fumagalli <pi...@betaversion.org>.
Remy Maucherat <re...@apache.org> wrote:
> Other that there are a lot of M$ ports (grr, XP ...), Tomcat is not
> misbehaving on that platform. I don't see any way so far to explain how
> it could be platform specific.
VM crap? I'll do some tests...
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: random BOUND socket (was Re: 5.0 proposal).
Posted by Remy Maucherat <re...@apache.org>.
jean-frederic clere wrote:
>
> I do see the following on my Linux:
> +++
> tcp 0 0 ::ffff:127.0.0:http-alt ::ffff:127.0.0.1:32893
> TIME_WAIT
> tcp 0 0 ::ffff:127.0.0.1:32892 ::ffff:127.0.0.1:8005
> TIME_WAIT
> tcp 0 0 ::ffff:127.0.0.1:32894 ::ffff:127.0.0.1:8009
> TIME_WAIT
> tcp 0 0 ::1:32891 ::1:32890
> TIME_WAIT
> +++
> The last line varies:
> +++
> tcp 0 0 ::1:32889 ::1:32888
> TIME_WAIT
> +++
> When Tomcat is stopped I do not have it.
On Windows/Cygwin, after starting Tomcat with:
- Coyote HTTP/1.1 on 8080
- HTTP/1.1 on 8083
- JK 2 on 8019
Here's what I have (TC is PID 3596, obviously):
$ netstat -ano
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 764
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 816
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING 1480
TCP 0.0.0.0:1484 0.0.0.0:0 LISTENING 980
TCP 0.0.0.0:1486 0.0.0.0:0 LISTENING 980
TCP 0.0.0.0:1627 0.0.0.0:0 LISTENING 1584
TCP 0.0.0.0:1862 0.0.0.0:0 LISTENING 1480
TCP 0.0.0.0:1884 0.0.0.0:0 LISTENING 1480
TCP 0.0.0.0:8019 0.0.0.0:0 LISTENING 3596
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 3596
TCP 0.0.0.0:8083 0.0.0.0:0 LISTENING 3596
TCP 127.0.0.1:25 0.0.0.0:0 LISTENING 1584
TCP 127.0.0.1:110 0.0.0.0:0 LISTENING 1584
TCP 127.0.0.1:1027 0.0.0.0:0 LISTENING 1480
TCP 127.0.0.1:1027 127.0.0.1:1028 ESTABLISHED 1480
TCP 127.0.0.1:1028 127.0.0.1:1027 ESTABLISHED 1480
TCP 127.0.0.1:2401 0.0.0.0:0 LISTENING 1584
TCP 127.0.0.1:5180 0.0.0.0:0 LISTENING 980
TCP 127.0.0.1:8005 0.0.0.0:0 LISTENING 3596
TCP 192.168.1.102:139 0.0.0.0:0 LISTENING 4
TCP 192.168.1.102:1484 64.12.29.4:5190 ESTABLISHED 980
TCP 192.168.1.102:1486 64.12.27.244:5190 ESTABLISHED 980
TCP 192.168.1.102:1627 63.251.56.143:22 ESTABLISHED 1584
TCP 192.168.1.102:1862 209.197.105.94:80 CLOSE_WAIT 1480
TCP 192.168.1.102:1884 209.197.105.94:80 CLOSE_WAIT 1480
TCP 192.168.1.102:2391 208.255.92.10:110 TIME_WAIT 0
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:1029 *:* 944
UDP 127.0.0.1:123 *:* 816
UDP 127.0.0.1:1190 *:* 384
UDP 192.168.1.102:123 *:* 816
UDP 192.168.1.102:137 *:* 4
UDP 192.168.1.102:138 *:* 4
Other that there are a lot of M$ ports (grr, XP ...), Tomcat is not
misbehaving on that platform. I don't see any way so far to explain how
it could be platform specific.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: random BOUND socket (was Re: 5.0 proposal).
Posted by Pier Fumagalli <pi...@betaversion.org>.
jean-frederic clere <jf...@fujitsu-siemens.com> wrote:
> I do see the following on my Linux:
> +++
> tcp 0 0 ::ffff:127.0.0:http-alt ::ffff:127.0.0.1:32893 TIME_WAIT
> tcp 0 0 ::ffff:127.0.0.1:32892 ::ffff:127.0.0.1:8005 TIME_WAIT
> tcp 0 0 ::ffff:127.0.0.1:32894 ::ffff:127.0.0.1:8009 TIME_WAIT
> tcp 0 0 ::1:32891 ::1:32890 TIME_WAIT
> +++
> The last line varies:
> +++
> tcp 0 0 ::1:32889 ::1:32888 TIME_WAIT
> +++
> When Tomcat is stopped I do not have it.
It seems that you are actually observing my same odd behavior... On Solaris,
when the TIME_WAIT expires, one of those sockets becomes "BOUND", as if
noone ever closed it...
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
random BOUND socket (was Re: 5.0 proposal).
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
> Pier Fumagalli wrote:
>
>> Remy Maucherat <re...@apache.org> wrote:
>>
>>
>>> I don't see that much to remove. I assume JNDI is the ever popular
>>> target, but I didn't notice it causing major problems (either
>>> performance or reliability), so I'd say it's not worth it.
>>
>>
>>
>> Actually, I have a complaint... 4.1.3 tries to write into my conf
>> directory:
>> especially the tomcat-users.xml.new file (and since the directory is read
>> only, the VM falls over).
>>
>> Call it defensive administration, but I don't want my engine to write a
>> single file if it's not where I tell him to do: /tmp. And for sure it
>> must
>> not attempt to modify my tomcat-users.xml.
>
> >
>
>> Only _root_ can do that, and if this is one of those things you call
>> "features", I call it a big huge security hole.
>
>
> Craig calls it a feature, so talk with him :)
>
> The new realm does that. If you look at the server.xml, you will notice
> you can still use the classic memory realm from 4.0 which doesn't do
> that instead of the new user database realm.
>
>> Attached there is a nice output of my logfile.
>>
>> Plus, about that random BOUND socket I had, I noticed it's a leftover
>> somehow in some friggin' initialization stage...
>>
>> My ports are 8005 (control) and 8080 (http/coyote)
>>
>> When I start up the thing it's all clear. I start 4.1.2 and notice:
>>
>> Local Address Remote Address Swind Send-Q Rwind Recv-Q State
>> --------------- --------------- ----- ------ ----- ------ ---------
>> localhost.8080 localhost.47420 32768 0 32768 0 TIME_WAIT
>> localhost.47422 localhost.47421 32768 0 32768 0 TIME_WAIT
>> *.8080 *.* 0 0 24576 0 LISTEN
>>
>> Why in the world is TC first of all opening a serversocket on port 47421?
>> (this port number always varies) what's going on here?
>
>
> I don't get that kind of odd behavior on Windows/Cygwin, so I can't help
> much here.
> No extra port gets bound in my configuration.
I do see the following on my Linux:
+++
tcp 0 0 ::ffff:127.0.0:http-alt ::ffff:127.0.0.1:32893 TIME_WAIT
tcp 0 0 ::ffff:127.0.0.1:32892 ::ffff:127.0.0.1:8005 TIME_WAIT
tcp 0 0 ::ffff:127.0.0.1:32894 ::ffff:127.0.0.1:8009 TIME_WAIT
tcp 0 0 ::1:32891 ::1:32890 TIME_WAIT
+++
The last line varies:
+++
tcp 0 0 ::1:32889 ::1:32888 TIME_WAIT
+++
When Tomcat is stopped I do not have it.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Remy Maucherat <re...@apache.org>.
Pier Fumagalli wrote:
> Remy Maucherat <re...@apache.org> wrote:
>
>
>>I don't see that much to remove. I assume JNDI is the ever popular
>>target, but I didn't notice it causing major problems (either
>>performance or reliability), so I'd say it's not worth it.
>
>
> Actually, I have a complaint... 4.1.3 tries to write into my conf directory:
> especially the tomcat-users.xml.new file (and since the directory is read
> only, the VM falls over).
>
> Call it defensive administration, but I don't want my engine to write a
> single file if it's not where I tell him to do: /tmp. And for sure it must
> not attempt to modify my tomcat-users.xml.
>
> Only _root_ can do that, and if this is one of those things you call
> "features", I call it a big huge security hole.
Craig calls it a feature, so talk with him :)
The new realm does that. If you look at the server.xml, you will notice
you can still use the classic memory realm from 4.0 which doesn't do
that instead of the new user database realm.
> Attached there is a nice output of my logfile.
>
> Plus, about that random BOUND socket I had, I noticed it's a leftover
> somehow in some friggin' initialization stage...
>
> My ports are 8005 (control) and 8080 (http/coyote)
>
> When I start up the thing it's all clear. I start 4.1.2 and notice:
>
> Local Address Remote Address Swind Send-Q Rwind Recv-Q State
> --------------- --------------- ----- ------ ----- ------ ---------
> localhost.8080 localhost.47420 32768 0 32768 0 TIME_WAIT
> localhost.47422 localhost.47421 32768 0 32768 0 TIME_WAIT
> *.8080 *.* 0 0 24576 0 LISTEN
>
> Why in the world is TC first of all opening a serversocket on port 47421?
> (this port number always varies) what's going on here?
I don't get that kind of odd behavior on Windows/Cygwin, so I can't help
much here.
No extra port gets bound in my configuration.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Pier Fumagalli wrote:
>
> Remy Maucherat <re...@apache.org> wrote:
>
> > I don't see that much to remove. I assume JNDI is the ever popular
> > target, but I didn't notice it causing major problems (either
> > performance or reliability), so I'd say it's not worth it.
>
> Actually, I have a complaint... 4.1.3 tries to write into my conf directory:
> especially the tomcat-users.xml.new file (and since the directory is read
> only, the VM falls over).
>
> Call it defensive administration, but I don't want my engine to write a
> single file if it's not where I tell him to do: /tmp. And for sure it must
> not attempt to modify my tomcat-users.xml.
>
> Only _root_ can do that, and if this is one of those things you call
> "features", I call it a big huge security hole.
>
I also would prefer that temporary files like that be put in a separate
location for security reasons. I will add that to my list of minor
changes to make.
>
> This are a couple of things that, apart from performances, tell me that no
> one ever actually tried to put this sucker in a _real_ production
> environment (I did, and it failed).
>
> Pier
>
I have 3 production instances of Tomcat 4.1 from recent CVS builds
(still using Jasper 1). All three use Apache 1.3.26 and mod_jk 1.2.
Two are low volume, one is medium volume (5-10k requests per day)
but with large peak loads several times a week.
The longest run I have gotten on the medium volume site is 4 weeks.
Getting to that point took alot of work tracking down problems.
It is performing fairly well now, but there are still cases where
Tomcat the container can't survive a web application problem.
A more robust Tomcat which can survive errant web applications is a
goal of mine.
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Pier Fumagalli <pi...@betaversion.org>.
Remy Maucherat <re...@apache.org> wrote:
> I don't see that much to remove. I assume JNDI is the ever popular
> target, but I didn't notice it causing major problems (either
> performance or reliability), so I'd say it's not worth it.
Actually, I have a complaint... 4.1.3 tries to write into my conf directory:
especially the tomcat-users.xml.new file (and since the directory is read
only, the VM falls over).
Call it defensive administration, but I don't want my engine to write a
single file if it's not where I tell him to do: /tmp. And for sure it must
not attempt to modify my tomcat-users.xml.
Only _root_ can do that, and if this is one of those things you call
"features", I call it a big huge security hole.
Attached there is a nice output of my logfile.
Plus, about that random BOUND socket I had, I noticed it's a leftover
somehow in some friggin' initialization stage...
My ports are 8005 (control) and 8080 (http/coyote)
When I start up the thing it's all clear. I start 4.1.2 and notice:
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
--------------- --------------- ----- ------ ----- ------ ---------
localhost.8080 localhost.47420 32768 0 32768 0 TIME_WAIT
localhost.47422 localhost.47421 32768 0 32768 0 TIME_WAIT
*.8080 *.* 0 0 24576 0 LISTEN
Why in the world is TC first of all opening a serversocket on port 47421?
(this port number always varies) what's going on here?
And why the hell does TC has to call himself up on port 8080? Is it
absolutely stupid?
Now one of TIME_WAIT (of course) expire (60 seconds in my kernel config) and
all seems back to normal:
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
--------------- --------------- ----- ------ ----- ------ ---------
localhost.47422 localhost.47421 32768 0 32768 0 TIME_WAIT
*.8080 *.* 0 0 24576 0 LISTEN
localhost.8005 *.* 0 0 24576 0 LISTEN
So, we can observe that FIRST TC disconnects to itself on port 8080, and
THEN on port 47422... (the first expiring is the first that got
disconnected)
And then the second expires as well...
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
--------------- --------------- ----- ------ ----- ------ ---------
*.47422 *.* 0 0 24576 0 BOUND
*.8080 *.* 0 0 24576 0 LISTEN
localhost.8005 *.* 0 0 24576 0 LISTEN
Uhoh... There you go... The stinkin' brat is still there.. A nice BOUND
socket, incredibly enough, the one that the connection was originated from,
but why did that socket had to connect to port 47421? Why isn't it closed
now? Why is it left hanging in my TCP stack? I can tell you that after 5
days it doesn't go away, therefore I believe that the Socket object to which
it refers to doesn't ever gets garbage collected...
A truss of what's going on: effectively, tomcat is doing a great job at
playing around with sockets, but for sure I don't get why it needs to
CONNECT (it's a dumb server), It does it two times, as reported by me
beautifully crafted Solaris kernel, On those connections, as far as I can
see, it never writes (or reads) anything,
/1: -> libsocket:socket(0x1a, 0x2, 0x0)
/1: <- libsocket:socket() = 5
/1: -> libsocket:socket(0x2, 0x2, 0x0)
/1: <- libsocket:socket() = 5
/1: -> libsocket:listen(0x5, 0x1)
/1: <- libsocket:listen() = 0
/1: -> libsocket:getsockname(0x5, 0x8046584, 0x80465b4)
/1: <- libsocket:getsockname() = 0
/1: -> libsocket:socket(0x2, 0x2, 0x0)
/1: <- libsocket:socket() = 6
/1: -> libsocket:connect(0x6, 0x8046584, 0x10)
/1: <- libsocket:connect() = 0
/1: -> libsocket:accept(0x5, 0x8046584, 0x80465b4)
/1: <- libsocket:accept() = 7
/1: -> libsocket:shutdown(0x6, 0x2)
/1: <- libsocket:shutdown() = 0
/1: -> libsocket:socket(0x2, 0x2, 0x0)
/1: <- libsocket:socket() = 5
/1: -> libsocket:setsockopt(0x5, 0xffff, 0x4, 0x8046834)
/1: <- libsocket:setsockopt() = 0
/1: -> libsocket:bind(0x5, 0x804685c, 0x10)
/1: <- libsocket:bind() = 0
/1: -> libsocket:listen(0x5, 0x32)
/1: <- libsocket:listen() = 0
/1: -> libsocket:socket(0x2, 0x2, 0x0)
/1: <- libsocket:socket() = 8
/1: -> libsocket:setsockopt(0x8, 0xffff, 0x4, 0x8046948)
/1: <- libsocket:setsockopt() = 0
/1: -> libsocket:bind(0x8, 0x8046970, 0x10)
/1: <- libsocket:bind() = 0
/1: -> libsocket:listen(0x8, 0x32)
/1: <- libsocket:listen() = 0
/1: -> libsocket:accept(0x8, 0x80469b0, 0x80469d0)
/22: -> libsocket:accept(0x5, 0xd1ec08d0, 0xd1ec08f0)
/22: <- libsocket:accept() = -1
/22: -> libsocket:accept(0x5, 0xd1ec08d0, 0xd1ec08f0)
/22: <- libsocket:accept() = 11
/22: -> libsocket:setsockopt(0xb, 0xffff, 0x80, 0xd1ec0844)
/22: <- libsocket:setsockopt() = 0
/22: -> libsocket:setsockopt(0xb, 0x6, 0x1, 0xd1ec0848)
/22: <- libsocket:setsockopt() = 0
/22: -> libsocket:send(0xb, 0xd1ebf718, 0xa8, 0x0)
/22: <- libsocket:send() = 168
/22: -> libsocket:send(0xb, 0xd1ebf734, 0x6, 0x0)
/22: <- libsocket:send() = 6
/22: -> libsocket:send(0xb, 0x8514960, 0x1cfb, 0x0)
/22: <- libsocket:send() = 7419
/22: -> libsocket:send(0xb, 0xd1ebf734, 0x2, 0x0)
/22: <- libsocket:send() = 2
/22: -> libsocket:send(0xb, 0xd1ebff6c, 0x5, 0x0)
/22: <- libsocket:send() = 5
/21: -> libsocket:accept(0x5, 0xd1f108d0, 0xd1f108f0)
/21: <- libsocket:accept() = 12
/21: -> libsocket:setsockopt(0xc, 0xffff, 0x80, 0xd1f10844)
/21: <- libsocket:setsockopt() = 0
/21: -> libsocket:setsockopt(0xc, 0x6, 0x1, 0xd1f10848)
/21: <- libsocket:setsockopt() = 0
/20: -> libsocket:accept(0x5, 0xd1f608d0, 0xd1f608f0)
/20: <- libsocket:accept() = 13
/20: -> libsocket:setsockopt(0xd, 0xffff, 0x80, 0xd1f60844)
/20: <- libsocket:setsockopt() = 0
/20: -> libsocket:setsockopt(0xd, 0x6, 0x1, 0xd1f60848)
/20: <- libsocket:setsockopt() = 0
/19: -> libsocket:accept(0x5, 0xd1fb08d0, 0xd1fb08f0)
/19: <- libsocket:accept() = 14
/19: -> libsocket:setsockopt(0xe, 0xffff, 0x80, 0xd1fb0844)
/19: <- libsocket:setsockopt() = 0
/21: -> libsocket:send(0xc, 0xd1f0fee4, 0xe3, 0x0)
/21: <- libsocket:send() = 227
/21: -> libsocket:send(0xc, 0xd1f0ff0c, 0x78e, 0x0)
/21: <- libsocket:send() = 1934
/19: -> libsocket:setsockopt(0xe, 0x6, 0x1, 0xd1fb0848)
/20: -> libsocket:send(0xd, 0xd1f5fee4, 0xe3, 0x0)
/20: <- libsocket:send() = 227
/19: <- libsocket:setsockopt() = 0
/20: -> libsocket:send(0xd, 0x8515a38, 0x1f46, 0x0)
/20: <- libsocket:send() = 8006
/19: -> libsocket:send(0xe, 0xd1fafee4, 0xe3, 0x0)
/19: <- libsocket:send() = 227
/19: -> libsocket:send(0xe, 0x83defe0, 0x914, 0x0)
/19: <- libsocket:send() = 2324
/1: <- libsocket:accept() = -1
/1: -> libsocket:accept(0x8, 0x80469b0, 0x80469d0)
/30: -> libsocket:socket(0x2, 0x2, 0x0)
/30: <- libsocket:socket() = 11
/30: -> libsocket:bind(0xb, 0xd1c4088c, 0x10)
/30: <- libsocket:bind() = 0
/30: -> libsocket:getsockname(0xb, 0xd1c4088c, 0xd1c408ac)
/30: <- libsocket:getsockname() = 0
/30: -> libsocket:connect(0xb, 0xd1c40744, 0x10)
/27: -> libsocket:accept(0x5, 0xd1d308d0, 0xd1d308f0)
/27: <- libsocket:accept() = 12
/30: <- libsocket:connect() = 0
For those who are interested in actually making the sucker work, and not
leaving up resources all around the place, I have the full truss output with
all system calls...
This are a couple of things that, apart from performances, tell me that no
one ever actually tried to put this sucker in a _real_ production
environment (I did, and it failed).
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]
Re: 5.0 proposal
Posted by Remy Maucherat <re...@apache.org>.
Pier Fumagalli wrote:
> I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and
> kiddies would start crying their butts off because they don't have the
> manager application, or JSP support :)
>
> But if anyone is interested I'd like to explore the opportunity of a
> Tomcat-HA (high-availability or hard-edition), based on 4.0 without the
> "crap" in there, and straightening out the request-response model...
If you just want to remove the extra features, then you can do that by
doing some JAR editing. That's not very hard to do.
> Simply, take the Catalina classes, and remove piles of useless stuff (more
> or less what Jon does for Scarab, but to a greater degree, maybe even
> reimplementing some of the Standard* classes).
I don't see that much to remove. I assume JNDI is the ever popular
target, but I didn't notice it causing major problems (either
performance or reliability), so I'd say it's not worth it.
Historically, the major reliability problems have been in the connectors
/ thread pooling code.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:
> On Mon, 24 Jun 2002, Pier Fumagalli wrote:
>
>> I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and
>> kiddies would start crying their butts off because they don't have the
>> manager application, or JSP support :)
>
> I don't think you can remove JSP support - tomcat would no longer be
> the 'reference impl. for servlets and jsps'.
>
> And I don't know why you have to _remove_ stuff that other people
> need and wrote - simply because you don't need them ?
Just when they complicate my life as an administrator... Look at what Scarab
is doing... Kudos to Jon who is actually doing it right...
>> But if anyone is interested I'd like to explore the opportunity of a
>> Tomcat-HA (high-availability or hard-edition), based on 4.0 without the
>> "crap" in there, and straightening out the request-response model...
>
> Sure - except the name, which will be 5.0 :-)
Yeah, right... I won't believe it until I won't see it with my own two
eyes...
> As I said, tomcat4.0 is out and in 'maintainance' mode ( like
> tomcat3.2 ). Changing APIs or removing features would require
> a very serious reason and would most likely be vetoed. Tuning and
> fixing and making smaller improvements is still possible - as long
> as the stability of the code is not affected.
I don't remember voting on that...
>>> I don't think you can 'veto' a long term plan or release. AFAIK it's
>>> a majority vote.
>>
>> Veto in terms of -1ing it.
>
> I think 'veto' has a very specific meaning. ( I'm not an expert in
> english, but it's not an english word :-)
>From Webster's Revised Unabridged Dictionary (1913) :
Veto \Ve"to\, n.; pl. Vetoes. [L. veto I forbid.]
1. An authoritative prohibition or negative; a forbidding; an
interdiction.
2. Specifically:
(a) A power or right possessed by one department of
government to forbid or prohibit the carrying out of
projects attempted by another department; especially,
in a constitutional government, a power vested in the
chief executive to prevent the enactment of measures
passed by the legislature.
Thank you, professor, always encouraging like a brick wall...
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by co...@covalent.net.
On Mon, 24 Jun 2002, Pier Fumagalli wrote:
> I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and
> kiddies would start crying their butts off because they don't have the
> manager application, or JSP support :)
I don't think you can remove JSP support - tomcat would no longer be
the 'reference impl. for servlets and jsps'.
And I don't know why you have to _remove_ stuff that other people
need and wrote - simply because you don't need them ?
> But if anyone is interested I'd like to explore the opportunity of a
> Tomcat-HA (high-availability or hard-edition), based on 4.0 without the
> "crap" in there, and straightening out the request-response model...
Sure - except the name, which will be 5.0 :-)
The whole idea is to improve the modularity of the code ( and the
smaller/cleaner request/response/hook model in Coyote is going to
help ), and allow more flexibility in configuration/packaging.
While the "RI" will likely consist of all the features, it should
be easy to remove or replace components you don't need in a particular
use-case, and release 'specialised' configuration ( like an 'embeded'
edition, 'standalone' or 'integrated', etc ).
As I said, tomcat4.0 is out and in 'maintainance' mode ( like
tomcat3.2 ). Changing APIs or removing features would require
a very serious reason and would most likely be vetoed. Tuning and
fixing and making smaller improvements is still possible - as long
as the stability of the code is not affected.
> > I don't think you can 'veto' a long term plan or release. AFAIK it's
> > a majority vote.
>
> Veto in terms of -1ing it.
I think 'veto' has a very specific meaning. ( I'm not an expert in
english, but it's not an english word :-)
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:
> On Mon, 24 Jun 2002, Pier Fumagalli wrote:
>
>> That's why counts where not right on my side of the border... I don't recall
>> vetoing the proposal... I just complained vehemently that I'd prefer to see
>> 4.0 out of the door and stable rather than a 4.1 and a 5.0...
>
> 4.0 is out of door - the release happened long ago. So did 4.0.1... 4.0.4.
>
> 4.1 is getting close - and it should be more stable and better than 4.0.4.
> And 5.0 should be more stable and better than 4.1 and 3.3.
>
> And 6.0 will probably be better than 5.0.
>
> If you are interested in maintaining and improving 4.0.4 - just volunteer
> as release manager for the branch, you have my +1 on it.
I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and
kiddies would start crying their butts off because they don't have the
manager application, or JSP support :)
But if anyone is interested I'd like to explore the opportunity of a
Tomcat-HA (high-availability or hard-edition), based on 4.0 without the
"crap" in there, and straightening out the request-response model...
Simply, take the Catalina classes, and remove piles of useless stuff (more
or less what Jon does for Scarab, but to a greater degree, maybe even
reimplementing some of the Standard* classes).
>> I can't veto as I don't really care how you want to spend your evenings and
>> stuff...
>
> I don't think you can 'veto' a long term plan or release. AFAIK it's
> a majority vote.
Veto in terms of -1ing it.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by co...@covalent.net.
On Mon, 24 Jun 2002, Pier Fumagalli wrote:
> That's why counts where not right on my side of the border... I don't recall
> vetoing the proposal... I just complained vehemently that I'd prefer to see
> 4.0 out of the door and stable rather than a 4.1 and a 5.0...
4.0 is out of door - the release happened long ago. So did 4.0.1... 4.0.4.
4.1 is getting close - and it should be more stable and better than 4.0.4.
And 5.0 should be more stable and better than 4.1 and 3.3.
And 6.0 will probably be better than 5.0.
If you are interested in maintaining and improving 4.0.4 - just volunteer
as release manager for the branch, you have my +1 on it.
> I can't veto as I don't really care how you want to spend your evenings and
> stuff...
I don't think you can 'veto' a long term plan or release. AFAIK it's
a majority vote.
Of course we should do our best to get everyone comfortable with the
plan ( at least +0 level ) - so more people will spend their evenings
helping :-)
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:
> On Mon, 24 Jun 2002, Pier Fumagalli wrote:
>
>> "costinm@covalent.net" <co...@covalent.net> wrote:
>>
>>> It seems we have 3 -1 votes so far.
>>
>> For completeness's sake, who are the 3 -1s? Not all the members of this list
>> have the entire day to read all that happens around here...
>
> Glenn, Christopher and you.
That's why counts where not right on my side of the border... I don't recall
vetoing the proposal... I just complained vehemently that I'd prefer to see
4.0 out of the door and stable rather than a 4.1 and a 5.0...
Let's put -1s and +1s in the mouth of the right people.
I can't veto as I don't really care how you want to spend your evenings and
stuff...
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by co...@covalent.net.
On Mon, 24 Jun 2002, Pier Fumagalli wrote:
> "costinm@covalent.net" <co...@covalent.net> wrote:
>
> > It seems we have 3 -1 votes so far.
>
> For completeness's sake, who are the 3 -1s? Not all the members of this list
> have the entire day to read all that happens around here...
Glenn, Christopher and you.
Costin
>
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 5.0 proposal
Posted by Pier Fumagalli <pi...@betaversion.org>.
"costinm@covalent.net" <co...@covalent.net> wrote:
> It seems we have 3 -1 votes so far.
For completeness's sake, who are the 3 -1s? Not all the members of this list
have the entire day to read all that happens around here...
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>