You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dr...@viaginterkom.de on 2001/12/29 23:09:37 UTC
Tomcat 3.3: ThreadPool bug (IS IT SAFE FOR PRODUCTION USE???)
Hi there,
I am trying to deploy our production service on the Tomcat 3.3 platform
(Solaris8, JDK 1.3.1) but am very often facing the instability problems.
Somehow, the ThreadPool just runs out of steam and blocks Connectors from
receiving any more requests.
Looking into the source code, I have noticed some very interesting
"constructions" in the ThreadPool class. Namely, the setters for the
maxThreads, maxSpareThreads and minSpareThreads are having very little
influence as the start() method is resseting the values to the default
constants ?!?!
public ThreadPool() {
maxThreads = MAX_THREADS;
maxSpareThreads = MAX_SPARE_THREADS;
minSpareThreads = MIN_SPARE_THREADS;
currentThreadCount = 0;
currentThreadsBusy = 0;
stopThePool = false;
}
public synchronized void start() {
stopThePool=false;
currentThreadCount = 0;
currentThreadsBusy = 0;
maxThreads = MAX_THREADS;
maxSpareThreads = MAX_SPARE_THREADS;
minSpareThreads = MIN_SPARE_THREADS;
adjustLimits();
openThreads(minSpareThreads);
monitor = new MonitorRunnable(this);
}
Also, the situation when there are no more available Threads in the pool is being handled in a special way which JUST BLOCKS IN THE INFINITE LOOP :
-(((
Is the code of the Tomcat4 equaly immature or there is a fair chance to
role a productiv system on top of it?
Thanks in advance for any comments
Drasko Kokic
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
[Ajp13] bad read: -103 error
Posted by yilmaz <yi...@hwajet.com.tw>.
Hi everybody,
does someone know what does "[Ajp13] bad read: -103 " error mean?
thanks :)
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Tomcat 3.3: ThreadPool bug (IS IT SAFE FOR PRODUCTION USE???)
Posted by Jeff Kilbride <je...@kilbride.com>.
Are you using Tomcat standalone or with Apache? If standalone, then yes, I
would recommend using the latest version of Tomcat 4.x. If you're using
Apache, I would stick with 3.3 until the mod_jk code is fully implemented
with the 4.x versions.
Thanks,
--jeff
----- Original Message -----
From: <Dr...@viaginterkom.de>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Saturday, December 29, 2001 2:09 PM
Subject: Tomcat 3.3: ThreadPool bug (IS IT SAFE FOR PRODUCTION USE???)
>
>
> Hi there,
>
> I am trying to deploy our production service on the Tomcat 3.3 platform
> (Solaris8, JDK 1.3.1) but am very often facing the instability problems.
> Somehow, the ThreadPool just runs out of steam and blocks Connectors from
> receiving any more requests.
>
> Looking into the source code, I have noticed some very interesting
> "constructions" in the ThreadPool class. Namely, the setters for the
> maxThreads, maxSpareThreads and minSpareThreads are having very little
> influence as the start() method is resseting the values to the default
> constants ?!?!
>
> public ThreadPool() {
> maxThreads = MAX_THREADS;
> maxSpareThreads = MAX_SPARE_THREADS;
> minSpareThreads = MIN_SPARE_THREADS;
> currentThreadCount = 0;
> currentThreadsBusy = 0;
> stopThePool = false;
> }
>
> public synchronized void start() {
> stopThePool=false;
> currentThreadCount = 0;
> currentThreadsBusy = 0;
> maxThreads = MAX_THREADS;
> maxSpareThreads = MAX_SPARE_THREADS;
> minSpareThreads = MIN_SPARE_THREADS;
>
> adjustLimits();
>
> openThreads(minSpareThreads);
> monitor = new MonitorRunnable(this);
> }
>
> Also, the situation when there are no more available Threads in the pool
is being handled in a special way which JUST BLOCKS IN THE INFINITE LOOP :
> -(((
>
> Is the code of the Tomcat4 equaly immature or there is a fair chance to
> role a productiv system on top of it?
>
> Thanks in advance for any comments
>
> Drasko Kokic
>
>
>
> --
> To unsubscribe: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>