You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Marc Saegesser <ma...@apropos.com> on 2001/02/13 04:50:53 UTC
Updating Tomcat3 Bugzilla items
I realize that the voting on Tomcat 3.2.2 is not complete yet, but I want to
get a head start on reviewing/updating Bugzilla reports against Tomcat 3.
There are currently 248 reports in the open/reopened/new states. All of
these need to be reviewed and addressed prior to finalizing 3.2.2. I will
be attempting to verify these bugs and either fix them, invalidate them (if
they aren't really bugs) or mark them as resolution=LATER. I am not an
expert in every detail of Tomcat and Jasper so if I can't determine if
something is a real bug of not I'll most likely just set the resolution to
LATER and move on. If I manage to get through 10 of these things a day
(probably unreasonable) it will still take almost a month. Obviously the
sooner I start the better.
I would ask that anyone who has committed fixes to the tomcat_32 branch
double check that the bug report has been closed. If anyone would like to
help review and update these things it would be *greatly* appreciated. If
you think I've incorrectly invalidated a bug please let me know.
Marc Saegesser
Re: Bug 1006, what's next ?
Posted by David Rees <db...@greenhydrant.com>.
On Tue, Mar 20, 2001 at 07:03:04AM -0800, cmanolache@yahoo.com wrote:
>
> I had a (long) weekend without computers. But I still found one and read
> the mail once - and your report is very serious and important ( and not
> easy to fix ). You have (at least ) my full attention. The read
> timeout will be checked in soon - but the general problem ( with a servlet
> hanging a thread ) is very hard to resolve (or I don't know any good
> solution ).
>
> We could stop setting an upper limit on the thread count ( we still have
> the OS upper limit ), and we could also use the (dangerous,
> deprecated) suspend/terminate on the thread that is taking too much time.
>
> Have you tried any fix ? The timeout will not resolve the "bursts" ( and
> high-loaded servers ) - unless it is very short.
>
> BTW, this is not a tomcat-specific problem ( I would guess Apache does
> have the same issue - and we need to find how they deal with that ).
Apache sets limits on the maximum (at least in 1.3.X, not sure about
2.X) number of processes which can be running at a time, this prevents
the machine from getting hosed, but doesn't prevent a DOS from a
determined attacker. I'm not sure if Apache implements any other methods
to prevent this type of DOS.
-Dave
RE: Bug 1006, what's next ?
Posted by Tal Dayan <ta...@zapta.com>.
Hi Mark,
Yes, we will be glad to test it.
BTW, we changed the code of the patch slightly. The timeout is now set even
if there is no factory. I am not
sure where these factories are coming from and whether it can be null but it
seems to be safer this way.
The change is documented in the bug report at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006
Tal
> -----Original Message-----
> From: Marc Saegesser [mailto:marc.saegesser@apropos.com]
> Sent: Tuesday, March 20, 2001 6:18 AM
> To: tomcat-dev@jakarta.apache.org
> Cc: tal@zapta.com
> Subject: RE: Bug 1006, what's next ?
>
>
> Tal,
>
> It has my attention. I'm in the process of finalizing the second beta
> release of Tomcat 3.2.2 and I will try to include this patch.
> Would you be
> able to test Tomcat 3.2.2 beta 2 (when its ready) to verify that this is
> working correctly?
>
> Marc Saegesser
>
> > -----Original Message-----
> > From: Tal Dayan [mailto:tal@zapta.com]
> > Sent: Tuesday, March 20, 2001 2:27 AM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Bug 1006, what's next ?
> >
> >
> >
> > Two days ago I filed a bug report regarding a sever hanging problem in
> > PollTcpEndpoint of Tomcat 3.x. The bug is
> > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> > also include a
> > suggestion for a patch.
> >
> > Since then I did not notice any change in the status or
> resolution of the
> > bug report nor any
> > indication that it got anywhere.
> >
> > 1. Is this is the right place to file the bug ?
> >
> > 2. Is the bug filed correctly ?
> >
> > 3. Should I do anything else to make sure the bug gets the
> > attention of the
> > relevant maintainers ?
> >
> > Thanks,
> >
> > Tal
> >
> >
>
>
RE: Bug 1006, what's next ?
Posted by Marc Saegesser <ma...@apropos.com>.
Tal,
It has my attention. I'm in the process of finalizing the second beta
release of Tomcat 3.2.2 and I will try to include this patch. Would you be
able to test Tomcat 3.2.2 beta 2 (when its ready) to verify that this is
working correctly?
Marc Saegesser
> -----Original Message-----
> From: Tal Dayan [mailto:tal@zapta.com]
> Sent: Tuesday, March 20, 2001 2:27 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Bug 1006, what's next ?
>
>
>
> Two days ago I filed a bug report regarding a sever hanging problem in
> PollTcpEndpoint of Tomcat 3.x. The bug is
> at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> also include a
> suggestion for a patch.
>
> Since then I did not notice any change in the status or resolution of the
> bug report nor any
> indication that it got anywhere.
>
> 1. Is this is the right place to file the bug ?
>
> 2. Is the bug filed correctly ?
>
> 3. Should I do anything else to make sure the bug gets the
> attention of the
> relevant maintainers ?
>
> Thanks,
>
> Tal
>
>
RE: Bug 1006, what's next ?
Posted by Tal Dayan <ta...@zapta.com>.
Yes, this is a typo. It should by 5.
Here is a verbatim paste of the statement we are using:
private static final int TIMEOUT = 5*60*1000; // read() timeout in ms
;-)
Tal
> -----Original Message-----
> From: Shawn McMurdo [mailto:shawn@lutris.com]
> Sent: Tuesday, March 20, 2001 12:55 PM
> To: tomcat-dev@jakarta.apache.org
> Cc: cmanolache@yahoo.com
> Subject: Re: Bug 1006, what's next ?
>
>
>
> Tal Dayan wrote:
>
> > [...]
> > Yes, we tested the timeout patch all day yesterday with a
> production system
> > with real users and normal load and
> > all the hanging threads and connections was cleaned up perfectly (we are
> > using 'netstat' to
> > get the number of HTTP connections and 'ps' to get the number
> of thread and
> > all is graphed around the clock by MRTG). We are running with a
> relatively
> > timeout of 5 minutes (50*60*1000) just to be on the safe side
> but a shorter
> > one can be used.
>
> Is 50 just a typo? Did you mean 5*60*1000?
> Just thought I'd mention it in case it affects your testing.
> Shawn
>
> --
> Shawn McMurdo mailto:shawn@lutris.com
> Lutris Technologies http://www.lutris.com
> Enhydra.Org http://www.enhydra.org
>
>
>
Re: Bug 1006, what's next ?
Posted by Shawn McMurdo <sh...@lutris.com>.
Tal Dayan wrote:
> [...]
> Yes, we tested the timeout patch all day yesterday with a production system
> with real users and normal load and
> all the hanging threads and connections was cleaned up perfectly (we are
> using 'netstat' to
> get the number of HTTP connections and 'ps' to get the number of thread and
> all is graphed around the clock by MRTG). We are running with a relatively
> timeout of 5 minutes (50*60*1000) just to be on the safe side but a shorter
> one can be used.
Is 50 just a typo? Did you mean 5*60*1000?
Just thought I'd mention it in case it affects your testing.
Shawn
--
Shawn McMurdo mailto:shawn@lutris.com
Lutris Technologies http://www.lutris.com
Enhydra.Org http://www.enhydra.org
Control Channel and Thread Pool (was bug 1006)
Posted by Tal Dayan <ta...@zapta.com>.
Hi Costin,
> The timeout patch will certainly go into tomcat3.3, and I think Marc will
> add it to 3.2 also - it's a good solution and I don't think it can brake
> anything.
Great, we will be able to drop soon our proprietry patches.zip library. ;-)
BTW, Our patch library currently contains three patches: the socketRead()
timeout path, the JSP class
encoding patch (to address NT's file name limit of 256 chars), and a patch
that eliminate the full disclosure that Tomcat does
regarding its version, the OS and its version and the JVM and its version
(we consider it to be a security issue, it will be nice to be able to
disable this disclosure or even set our own string for an out of the box
Tomcat).
> I was thinking about what we can do for a more general solution - and
> looking at the code I think there are few easy things that need to be
> done related with thread pools:
>
> - use a common thread pool for all endpoints ( right now ajp12 is creating
> a full thread pool for itself, etc).
Yes, this will be more efficient. For example, the current standlone version
allocates 10 threads by default
for the Ajp connector even though only few may be needed for shutdown. The
problem however is that if you will get
to the max threads, you will not be able to shutdown Tomcat.
> - document the thread pool implementation, remove some old code
>
> - add an admin page to monitor the thread pools
Here is a simple idea that works well for us and will bring great benefit to
the
entire Jakarta project (unless it already exists ;-))
We have in our application a Control mechanism that allows to send commands
and get information from various parts of the application. It is build in a
modular way such that every module can add its command handlers dynamically.
This way, you have very good access to the internals of the server and the
application. Somthing similar to SNMP but simpler.
Then you can use this mechnaism to get any status information from any
module (e.g. ThreadPool), send commands etc. The access to this control can
be with Java API, servlet that uses HTMl or XML, SOAP, XMLRPC, etc and you
can access all of the status and control points in a uniform way.
In our case, the access is done both using Java API and through a servlet.
The servlet present an interactive form in which you can post the commands
and see the results. We also have a simple command-line client (writen in
Java) that allows to send the commands and get the status from a command
line (great for scripting).
We can release the source code of it but I think it will be better if it is
redisgned and implemented in a more general way. This will be easy to do and
will brings great benifit.
> - use the thread pool to run session expire and verify the expire bugs
> - add a ThreadPoolListener/Event to allow a (future) module to monitor and
> manage the thread pool
>
> - add a field to store the current "owner" or "user" of each thread.
Yes, this will be very useful. And with the above control mechanism you will
be able to get not just the status of the pool but also things like how long
does each worker is performing the current task (since it was allocated from
the pool).
BTW, this can be improved even with the current code. Currently when you
perform a thread/stack dump of the JVM, you can see all the threads that are
waiting in the thread pools but you don't know which is which. Setting the
thread names to something like 'PoolName-01' instead of 'Thread-01' will be
very useful.
> - add some log messages for the case when the thread pool is at the
> maximum capacity
Yes, and if you can control the verbosity levels in your logs, you can also
report when they are freed or periodically (by the control thread of the
pool) what is the status of the pool. And with the control mechanism, you
will be able to easily play with all kind of scenarios, for example, by
changing pool parameters while the server is running, issue 'free all unused
thread', or 'abort thread 34' commands, increase the verbosity level of the
thread pool log, etc.
> - maybe provide a spare "admin" thread that can be used to "un-hang" the
> server without restarting tomcat ( i.e. if the thread pool is at max
> capacity, and if the connector detects a localhost connection allow it to
> create an extra thread - so an admin application can kill threads ).
Maybe you can detect the this bad conditions, you may use the control thread
of the thread pool to
abort hanging threads. And with the external control mechanism, you can even
have external monitoring programs to issue a 'soft reset' command to Tomcat.
> - API change in ThreadPool - allow it to run normal Runnable ( the current
> ThreadPoolRunnable has some nice performance tricks, but it should be
> usable for normal tasks that don't want to take advantage of overhead-free
> thread data )
>
> None of those would resolve the DOS problem, but I think it would be nice
> to have them (and very easy to implement - without affecting the current
> functionality )
Yes, it is hard to have a DOS safe solution (e.g. how do you handle
excessive creation of sessions). The first priority IMHO should be to make
the thing work well in normal conditions without introducing new
vulnerabilities.
>
>
> Costin
>
Tal
>
>
>
>
> On Tue, 20 Mar 2001, Tal Dayan wrote:
>
> > Hi,
> >
> > Our first priority is to make Tomcat to work in normal
> conditions with good
> > intentioned users. We will
> > worry later about DOS (as long as we don't introduce new
> vulnerabilities).
> >
> > Yes, we tested the timeout patch all day yesterday with a
> production system
> > with real users and normal load and
> > all the hanging threads and connections was cleaned up perfectly (we are
> > using 'netstat' to
> > get the number of HTTP connections and 'ps' to get the number
> of thread and
> > all is graphed around the clock by MRTG). We are running with a
> relatively
> > timeout of 5 minutes (50*60*1000) just to be on the safe side
> but a shorter
> > one can be used.
> >
> > Note that I am in no way and expert in Tomcat nor do I claim to
> understand
> > all the implications of the patch so we need some qualified person to
> > understand the implication and make sure it does not break anything. For
> > example, if another service like Ajp uses this connection pool
> for long term
> > connections that need to wait long periods for a data from some
> client (e.g.
> > a front end web server, client side applets, etc), the patch
> will break it.
> > The patch assumes that the connections are should never be idle
> for a long
> > period of time.
> >
> > As for Apache, it supports a request timeout (see
> > http://httpd.apache.org/docs/mod/core.html#timeout) and this will
> > will eventually cleanup hanging connections. The timeout in this case is
> > longer because it is for the entire request and the cleanup
> will be slower.
> >
> > Implementing a similar query timeout in Tomcat may require things like
> > asynchronous thread kill (yuck) or some synchronous termination of the
> > worker threads, for example by closing the sockets they are
> waiting on (I
> > think this will release the socketRead() but I am not sure).
> But this is of
> > course a more involved change than simply adding the timeout statement.
> > Having an asynchronous I/O may help here (see Bug Parade
> > http://developer.java.sun.com/developer/bugParade/bugs/4075058.html).
> >
> > BTW, does Tomcat 4.X has the same problem ?
> >
> > Tal
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > > Sent: Tuesday, March 20, 2001 7:03 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > Subject: Re: Bug 1006, what's next ?
> > >
> > >
> > > Hi,
> > >
> > > I had a (long) weekend without computers. But I still found
> one and read
> > > the mail once - and your report is very serious and important
> ( and not
> > > easy to fix ). You have (at least ) my full attention. The read
> > > timeout will be checked in soon - but the general problem
> with a servlet
> > > hanging a thread ) is very hard to resolve (or I don't know any good
> > > solution ).
> > >
> > > We could stop setting an upper limit on the thread count ( we
> still have
> > > the OS upper limit ), and we could also use the (dangerous,
> > > deprecated) suspend/terminate on the thread that is taking
> too much time.
> > >
> > > Have you tried any fix ? The timeout will not resolve the
> "bursts" ( and
> > > high-loaded servers ) - unless it is very short.
> > >
> > > BTW, this is not a tomcat-specific problem ( I would guess Apache does
> > > have the same issue - and we need to find how they deal with that ).
> > >
> > > Costin
> > >
> > >
> > > On Tue, 20 Mar 2001, Tal Dayan wrote:
> > >
> > > >
> > > > Two days ago I filed a bug report regarding a sever hanging
> problem in
> > > > PollTcpEndpoint of Tomcat 3.x. The bug is
> > > > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> > > also include a
> > > > suggestion for a patch.
> > > >
> > > > Since then I did not notice any change in the status or
> > > resolution of the
> > > > bug report nor any
> > > > indication that it got anywhere.
> > > >
> > > > 1. Is this is the right place to file the bug ?
> > > >
> > > > 2. Is the bug filed correctly ?
> > > >
> > > > 3. Should I do anything else to make sure the bug gets the
> > > attention of the
> > > > relevant maintainers ?
> > > >
> > > > Thanks,
> > > >
> > > > Tal
> > > >
> > > >
> > >
> > >
> >
>
>
>
RE: Bug 1006, what's next ?
Posted by cm...@yahoo.com.
Hi Tal,
The timeout patch will certainly go into tomcat3.3, and I think Marc will
add it to 3.2 also - it's a good solution and I don't think it can brake
anything.
I was thinking about what we can do for a more general solution - and
looking at the code I think there are few easy things that need to be
done related with thread pools:
- use a common thread pool for all endpoints ( right now ajp12 is creating
a full thread pool for itself, etc).
- document the thread pool implementation, remove some old code
- add an admin page to monitor the thread pools
- use the thread pool to run session expire and verify the expire bugs
- add a ThreadPoolListener/Event to allow a (future) module to monitor and
manage the thread pool
- add a field to store the current "owner" or "user" of each thread.
- add some log messages for the case when the thread pool is at the
maximum capacity
- maybe provide a spare "admin" thread that can be used to "un-hang" the
server without restarting tomcat ( i.e. if the thread pool is at max
capacity, and if the connector detects a localhost connection allow it to
create an extra thread - so an admin application can kill threads ).
- API change in ThreadPool - allow it to run normal Runnable ( the current
ThreadPoolRunnable has some nice performance tricks, but it should be
usable for normal tasks that don't want to take advantage of overhead-free
thread data )
None of those would resolve the DOS problem, but I think it would be nice
to have them (and very easy to implement - without affecting the current
functionality )
Costin
On Tue, 20 Mar 2001, Tal Dayan wrote:
> Hi,
>
> Our first priority is to make Tomcat to work in normal conditions with good
> intentioned users. We will
> worry later about DOS (as long as we don't introduce new vulnerabilities).
>
> Yes, we tested the timeout patch all day yesterday with a production system
> with real users and normal load and
> all the hanging threads and connections was cleaned up perfectly (we are
> using 'netstat' to
> get the number of HTTP connections and 'ps' to get the number of thread and
> all is graphed around the clock by MRTG). We are running with a relatively
> timeout of 5 minutes (50*60*1000) just to be on the safe side but a shorter
> one can be used.
>
> Note that I am in no way and expert in Tomcat nor do I claim to understand
> all the implications of the patch so we need some qualified person to
> understand the implication and make sure it does not break anything. For
> example, if another service like Ajp uses this connection pool for long term
> connections that need to wait long periods for a data from some client (e.g.
> a front end web server, client side applets, etc), the patch will break it.
> The patch assumes that the connections are should never be idle for a long
> period of time.
>
> As for Apache, it supports a request timeout (see
> http://httpd.apache.org/docs/mod/core.html#timeout) and this will
> will eventually cleanup hanging connections. The timeout in this case is
> longer because it is for the entire request and the cleanup will be slower.
>
> Implementing a similar query timeout in Tomcat may require things like
> asynchronous thread kill (yuck) or some synchronous termination of the
> worker threads, for example by closing the sockets they are waiting on (I
> think this will release the socketRead() but I am not sure). But this is of
> course a more involved change than simply adding the timeout statement.
> Having an asynchronous I/O may help here (see Bug Parade
> http://developer.java.sun.com/developer/bugParade/bugs/4075058.html).
>
> BTW, does Tomcat 4.X has the same problem ?
>
> Tal
>
>
>
>
> > -----Original Message-----
> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > Sent: Tuesday, March 20, 2001 7:03 AM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: Bug 1006, what's next ?
> >
> >
> > Hi,
> >
> > I had a (long) weekend without computers. But I still found one and read
> > the mail once - and your report is very serious and important ( and not
> > easy to fix ). You have (at least ) my full attention. The read
> > timeout will be checked in soon - but the general problem ( with a servlet
> > hanging a thread ) is very hard to resolve (or I don't know any good
> > solution ).
> >
> > We could stop setting an upper limit on the thread count ( we still have
> > the OS upper limit ), and we could also use the (dangerous,
> > deprecated) suspend/terminate on the thread that is taking too much time.
> >
> > Have you tried any fix ? The timeout will not resolve the "bursts" ( and
> > high-loaded servers ) - unless it is very short.
> >
> > BTW, this is not a tomcat-specific problem ( I would guess Apache does
> > have the same issue - and we need to find how they deal with that ).
> >
> > Costin
> >
> >
> > On Tue, 20 Mar 2001, Tal Dayan wrote:
> >
> > >
> > > Two days ago I filed a bug report regarding a sever hanging problem in
> > > PollTcpEndpoint of Tomcat 3.x. The bug is
> > > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> > also include a
> > > suggestion for a patch.
> > >
> > > Since then I did not notice any change in the status or
> > resolution of the
> > > bug report nor any
> > > indication that it got anywhere.
> > >
> > > 1. Is this is the right place to file the bug ?
> > >
> > > 2. Is the bug filed correctly ?
> > >
> > > 3. Should I do anything else to make sure the bug gets the
> > attention of the
> > > relevant maintainers ?
> > >
> > > Thanks,
> > >
> > > Tal
> > >
> > >
> >
> >
>
RE: Bug 1006, what's next ?
Posted by Tal Dayan <ta...@zapta.com>.
Hi,
Our first priority is to make Tomcat to work in normal conditions with good
intentioned users. We will
worry later about DOS (as long as we don't introduce new vulnerabilities).
Yes, we tested the timeout patch all day yesterday with a production system
with real users and normal load and
all the hanging threads and connections was cleaned up perfectly (we are
using 'netstat' to
get the number of HTTP connections and 'ps' to get the number of thread and
all is graphed around the clock by MRTG). We are running with a relatively
timeout of 5 minutes (50*60*1000) just to be on the safe side but a shorter
one can be used.
Note that I am in no way and expert in Tomcat nor do I claim to understand
all the implications of the patch so we need some qualified person to
understand the implication and make sure it does not break anything. For
example, if another service like Ajp uses this connection pool for long term
connections that need to wait long periods for a data from some client (e.g.
a front end web server, client side applets, etc), the patch will break it.
The patch assumes that the connections are should never be idle for a long
period of time.
As for Apache, it supports a request timeout (see
http://httpd.apache.org/docs/mod/core.html#timeout) and this will
will eventually cleanup hanging connections. The timeout in this case is
longer because it is for the entire request and the cleanup will be slower.
Implementing a similar query timeout in Tomcat may require things like
asynchronous thread kill (yuck) or some synchronous termination of the
worker threads, for example by closing the sockets they are waiting on (I
think this will release the socketRead() but I am not sure). But this is of
course a more involved change than simply adding the timeout statement.
Having an asynchronous I/O may help here (see Bug Parade
http://developer.java.sun.com/developer/bugParade/bugs/4075058.html).
BTW, does Tomcat 4.X has the same problem ?
Tal
> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Tuesday, March 20, 2001 7:03 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Bug 1006, what's next ?
>
>
> Hi,
>
> I had a (long) weekend without computers. But I still found one and read
> the mail once - and your report is very serious and important ( and not
> easy to fix ). You have (at least ) my full attention. The read
> timeout will be checked in soon - but the general problem ( with a servlet
> hanging a thread ) is very hard to resolve (or I don't know any good
> solution ).
>
> We could stop setting an upper limit on the thread count ( we still have
> the OS upper limit ), and we could also use the (dangerous,
> deprecated) suspend/terminate on the thread that is taking too much time.
>
> Have you tried any fix ? The timeout will not resolve the "bursts" ( and
> high-loaded servers ) - unless it is very short.
>
> BTW, this is not a tomcat-specific problem ( I would guess Apache does
> have the same issue - and we need to find how they deal with that ).
>
> Costin
>
>
> On Tue, 20 Mar 2001, Tal Dayan wrote:
>
> >
> > Two days ago I filed a bug report regarding a sever hanging problem in
> > PollTcpEndpoint of Tomcat 3.x. The bug is
> > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> also include a
> > suggestion for a patch.
> >
> > Since then I did not notice any change in the status or
> resolution of the
> > bug report nor any
> > indication that it got anywhere.
> >
> > 1. Is this is the right place to file the bug ?
> >
> > 2. Is the bug filed correctly ?
> >
> > 3. Should I do anything else to make sure the bug gets the
> attention of the
> > relevant maintainers ?
> >
> > Thanks,
> >
> > Tal
> >
> >
>
>
Re: Bug 1006, what's next ?
Posted by cm...@yahoo.com.
Hi,
I had a (long) weekend without computers. But I still found one and read
the mail once - and your report is very serious and important ( and not
easy to fix ). You have (at least ) my full attention. The read
timeout will be checked in soon - but the general problem ( with a servlet
hanging a thread ) is very hard to resolve (or I don't know any good
solution ).
We could stop setting an upper limit on the thread count ( we still have
the OS upper limit ), and we could also use the (dangerous,
deprecated) suspend/terminate on the thread that is taking too much time.
Have you tried any fix ? The timeout will not resolve the "bursts" ( and
high-loaded servers ) - unless it is very short.
BTW, this is not a tomcat-specific problem ( I would guess Apache does
have the same issue - and we need to find how they deal with that ).
Costin
On Tue, 20 Mar 2001, Tal Dayan wrote:
>
> Two days ago I filed a bug report regarding a sever hanging problem in
> PollTcpEndpoint of Tomcat 3.x. The bug is
> at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and also include a
> suggestion for a patch.
>
> Since then I did not notice any change in the status or resolution of the
> bug report nor any
> indication that it got anywhere.
>
> 1. Is this is the right place to file the bug ?
>
> 2. Is the bug filed correctly ?
>
> 3. Should I do anything else to make sure the bug gets the attention of the
> relevant maintainers ?
>
> Thanks,
>
> Tal
>
>
Bug 1006, what's next ?
Posted by Tal Dayan <ta...@zapta.com>.
Two days ago I filed a bug report regarding a sever hanging problem in
PollTcpEndpoint of Tomcat 3.x. The bug is
at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and also include a
suggestion for a patch.
Since then I did not notice any change in the status or resolution of the
bug report nor any
indication that it got anywhere.
1. Is this is the right place to file the bug ?
2. Is the bug filed correctly ?
3. Should I do anything else to make sure the bug gets the attention of the
relevant maintainers ?
Thanks,
Tal
Re: Updating Tomcat3 Bugzilla items
Posted by Dan Milstein <da...@shore.net>.
I've assigned most of the mod_jk connector bugs to myself, and will try to
do this same work (verifying -> resolving and/or markings as LATER). I've
also closed out a few which I know are fixed. I've been marking them as
part of the "Nightly Build" if the fixes are slated to be part of 3.2.2
(most of the bugs came from BugRat, and, as such aren't specified against a
particular version). I think that makes sense, since they are fixed in the
Nightly Build (even if they were reported against 3.2.1 or 3.1 or
something).
I haven't picked up any of the NT-related mod_jk bugs (and there are a few),
since I have zero ability to test anything NT-related.
-Dan
Marc Saegesser wrote:
>
> I realize that the voting on Tomcat 3.2.2 is not complete yet, but I want to
> get a head start on reviewing/updating Bugzilla reports against Tomcat 3.
>
> There are currently 248 reports in the open/reopened/new states. All of
> these need to be reviewed and addressed prior to finalizing 3.2.2. I will
> be attempting to verify these bugs and either fix them, invalidate them (if
> they aren't really bugs) or mark them as resolution=LATER. I am not an
> expert in every detail of Tomcat and Jasper so if I can't determine if
> something is a real bug of not I'll most likely just set the resolution to
> LATER and move on. If I manage to get through 10 of these things a day
> (probably unreasonable) it will still take almost a month. Obviously the
> sooner I start the better.
>
> I would ask that anyone who has committed fixes to the tomcat_32 branch
> double check that the bug report has been closed. If anyone would like to
> help review and update these things it would be *greatly* appreciated. If
> you think I've incorrectly invalidated a bug please let me know.
>
> Marc Saegesser
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
Dan Milstein // danmil@shore.net