You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Matthew Hannigan <ml...@zip.com.au> on 2002/11/06 22:47:25 UTC

lots of tomcat processes (Re: [PATCH][JK] Ajp13Processor connection leak prevention)

On Wed, Nov 06, 2002 at 12:10:09AM -0800, Daniel Rall wrote:
> Adjusted Ajp13Processor's run() method to protect against unexpected
> unchecked excpetions, preventing the possibility of a leak in
> Ajp13Connector's request processor pool.
> [ patch elided ]

Would this cause hanging tomcat instances?  I get a multiplying
lot of tomcat processes after a while.  How many should there
be?

Just one? i.e., is a 'request processor' a java thread or an
OS process?

Using apache1.3.27, mod_jk1.2.0, tomcat 4.0.4 (soon to be 4.0.6)
on Solaris8.

Regards,

Matt




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: lots of tomcat processes (Re: [PATCH][JK] Ajp13Processor connection leak prevention)

Posted by Matthew Hannigan <ml...@zip.com.au>.
On Wed, Nov 06, 2002 at 02:01:42PM -0800, Daniel Rall wrote:
> > I get a multiplying lot of tomcat processes after a while.  How many
> > should there be?
> 
> This probably depends on your OS/JVM's threading model.  On Linux,
> this is perfectly normal.
> 
> > Just one? i.e., is a 'request processor' a java thread or an
> > OS process?
> 
> A request processor is a Java thread, the implementation of which is
> OS-specific, varying depending upon your platform.

I'm fairly sure that Solaris uses exactly one process consisting
of multiple threads.  I checked one of the processes with
ps -L -p <pid> and it showed 9 lightweith processes in that
one unix process.

It looks like all but one of the Unix processes is rogue.

Now to find out which one ...

I'll try your patch and try and let you know how it goes.

Thanks for your reply Daniel!

Regards,
Matt

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: lots of tomcat processes (Re: [PATCH][JK] Ajp13Processor connection leak prevention)

Posted by Daniel Rall <dl...@finemaltcoding.com>.
Matthew Hannigan <ml...@zip.com.au> writes:

> On Wed, Nov 06, 2002 at 12:10:09AM -0800, Daniel Rall wrote:
> > Adjusted Ajp13Processor's run() method to protect against unexpected
> > unchecked excpetions, preventing the possibility of a leak in
> > Ajp13Connector's request processor pool.
> > [ patch elided ]
> 
> Would this cause hanging tomcat instances?

I assume it could, yes.  mod_jk would open a socket connection to
Tomcat (which for some reason accept()'s connections before it checks
whether request processors are available -- without knowing the
reasoning behind this, it seems like bad behavior), but Tomcat will
close the socket if it has no request processors available,
effectively making Tomcat appear to "hang".  You would actually have
to be leaking request processors, perhaps due to the occurance of
unchecked exceptions (that this patch addresses) for this situation to
occur.  The default number of request processors is 20 -- you can
change this in server.xml (it should be equal to MaxClients in your
httpd.conf), or set it <= 0 for an unlimited number.

> I get a multiplying lot of tomcat processes after a while.  How many
> should there be?

This probably depends on your OS/JVM's threading model.  On Linux,
this is perfectly normal.

> Just one? i.e., is a 'request processor' a java thread or an
> OS process?

A request processor is a Java thread, the implementation of which is
OS-specific, varying depending upon your platform.

> Using apache1.3.27, mod_jk1.2.0, tomcat 4.0.4 (soon to be 4.0.6)
> on Solaris8.

I'm not certain how the JVM on Solaris implements threading.  For
instance, on Linux, for a long time the JVM included its own threading
implementation (green threads) which were generally more robust than
Linux's threading implementation (RedHat 6.x), but slower.  Now a
days, OS threads on Linux are preferable to green threads.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>