You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alec Swan <al...@gmail.com> on 2011/01/14 00:05:04 UTC

Dedicated thread for Tomcat Manager

Hello,

Our webapp gets periodically hammered by our client applications causing
Tomcat to run out of threads. This prevents us from being able to use Tomcat
Manager and check the server status.

Is there a way to assign a dedicated thread to Tomcat Manager so that it
will never be used to process any other client requests?

Thanks

Re: Dedicated thread for Tomcat Manager

Posted by Mark Thomas <ma...@apache.org>.
On 13/01/2011 23:05, Alec Swan wrote:
> Hello,
> 
> Our webapp gets periodically hammered by our client applications causing
> Tomcat to run out of threads. This prevents us from being able to use Tomcat
> Manager and check the server status.
> 
> Is there a way to assign a dedicated thread to Tomcat Manager so that it
> will never be used to process any other client requests?

The short answer is no.

The longer answer is take a look at the SemaphoreValve. You should be
able to subclass that and override controlConcurrency. Something along
the lines of limit all users from non-admin IPs to 390 concurrent
requests and have 400 threads on the connector.

Just be aware I'm not sure how widely used (and hence tested) that valve
is. On the other hand Remy wrote it so the chances of it failing are
pretty slim.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Dedicated thread for Tomcat Manager

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alec,

On 1/14/2011 1:04 PM, Alec Swan wrote:
> Mark and Charles, thank you for the recommendations.
> 
> Which approach - separate <Connector> or JMX access - is more appropriate
> for production environments? Could you briefly describe pros and cons of
> each of them?

That depends on what you want to do: if the information you need is
available via JMX, that seems most appropriate. If you have home-grown
tools that you want to expose via a web interface, the <Connector> is
more appropriate.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0wqTYACgkQ9CaO5/Lv0PCHaACePRKCk4lPm003xdmNYubi9wK8
X6EAn0/gjxdL0yuubGSyeKDLWjYuKKpB
=AUWf
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Dedicated thread for Tomcat Manager

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Alec Swan [mailto:alecswan@gmail.com] 
> Subject: Re: Dedicated thread for Tomcat Manager

> I am assuming this new connector will serve all webapps, 
> including Tomcat manager.

Correct.  You could implement a <Valve> at the <Engine> or <Host> level to prevent its use for other webapps, but if you only expose that IP:port to your internal network, why bother?
 
 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Dedicated thread for Tomcat Manager

Posted by Alec Swan <al...@gmail.com>.
Thank you everybody who contributed for explaining the pros and cons.

We will go with the <Connector> approach. I am assuming this new connector
will serve all webapps, including Tomcat manager. Or can I configure it to
serve just Tomcat Manager?

Thanks

On Fri, Jan 14, 2011 at 2:02 PM, André Warnier <aw...@ice-sa.com> wrote:

> Caldarale, Charles R wrote:
>
>> From: André Warnier [mailto:aw@ice-sa.com] Subject: Re: Dedicated thread
>>> for Tomcat Manager
>>>
>>
>>  My opinion was not asked, but I would tend to say that the solution with
>>> a separate Connector sounds so evidently simple
>>> in the principle (once it has been pointed out by the clever
>>> guy) that it ought to win this hands down.
>>>
>>
>> The only caveat is that there's a *lot* more information available via
>> JMX, if you need it and want to spend the effort to dig it out.  The
>> appropriate solution depends on the site requirements.
>>
>>  Sure.  But don't be overly modest now.  The original question was about
> keeping the Tomcat Manager application accessible even when all the
> application threads are busy, and I think that the separate Connector
> answers that perfectly.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Dedicated thread for Tomcat Manager

Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: André Warnier [mailto:aw@ice-sa.com] 
>> Subject: Re: Dedicated thread for Tomcat Manager
> 
>> My opinion was not asked, but I would tend to say that the 
>> solution with a separate Connector sounds so evidently simple
>> in the principle (once it has been pointed out by the clever
>> guy) that it ought to win this hands down.
> 
> The only caveat is that there's a *lot* more information available via JMX, if you need it and want to spend the effort to dig it out.  The appropriate solution depends on the site requirements.
> 
Sure.  But don't be overly modest now.  The original question was about keeping the 
Tomcat Manager application accessible even when all the application threads are busy, and 
I think that the separate Connector answers that perfectly.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Dedicated thread for Tomcat Manager

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com] 
> Subject: Re: Dedicated thread for Tomcat Manager

> My opinion was not asked, but I would tend to say that the 
> solution with a separate Connector sounds so evidently simple
> in the principle (once it has been pointed out by the clever
> guy) that it ought to win this hands down.

The only caveat is that there's a *lot* more information available via JMX, if you need it and want to spend the effort to dig it out.  The appropriate solution depends on the site requirements.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Dedicated thread for Tomcat Manager

Posted by André Warnier <aw...@ice-sa.com>.
Alec Swan wrote:
> Mark and Charles, thank you for the recommendations.
> 
> Which approach - separate <Connector> or JMX access - is more appropriate
> for production environments? Could you briefly describe pros and cons of
> each of them?
> 
My opinion was not asked, but I would tend to say that the solution with a separate 
Connector sounds so evidently simple in the principle (once it has been pointed out by the 
clever guy) that it ought to win this hands down.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Dedicated thread for Tomcat Manager

Posted by Alec Swan <al...@gmail.com>.
Mark and Charles, thank you for the recommendations.

Which approach - separate <Connector> or JMX access - is more appropriate
for production environments? Could you briefly describe pros and cons of
each of them?

Thanks!

Alec

On Thu, Jan 13, 2011 at 4:30 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:

> > From: Alec Swan [mailto:alecswan@gmail.com]
> > Subject: Dedicated thread for Tomcat Manager
>
> > Is there a way to assign a dedicated thread to Tomcat Manager so
> > that it will never be used to process any other client requests?
>
> Not directly - threads are associated with a <Connector> or <Executor>, not
> a webapp.  You could define an additional <Connector> on a unique port that
> you use to access the manager webapp.  Or you could use a JMX tool instead,
> such as JConsole.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

RE: Dedicated thread for Tomcat Manager

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Alec Swan [mailto:alecswan@gmail.com] 
> Subject: Dedicated thread for Tomcat Manager

> Is there a way to assign a dedicated thread to Tomcat Manager so
> that it will never be used to process any other client requests?

Not directly - threads are associated with a <Connector> or <Executor>, not a webapp.  You could define an additional <Connector> on a unique port that you use to access the manager webapp.  Or you could use a JMX tool instead, such as JConsole.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org