Thanks Mark Thomas ,

   Our application is access by Apache TO Tomcat using AJP Connector.

    Problem :
    Our application was mostly hanged,after looking at tomcat manager it
shown there are so many long running threads shown.
    We want to recognize why so many threads are running since long time.
    We want to detect such thread and want to kill these stucked thread.





On 5 October 2015 at 13:11, Mark Thomas <ma...@apache.org> wrote:

> On 05/10/2015 07:54, Yogesh Patel wrote:
> >         We are facing issues with long running thread in tomcat . we are
> > using Tomcat-7.0.47.Tomcat manager shows Current busy threads : 200,
> > application  gets stucked due to these long running threads.
>
> What makes you think you have issues with long running threads? A busy
> thread isn't necessarily processing a request. Configuration errors
> leading to thread starvation are a more typical cause of the symptom you
> describe rather than long running threads in the application.
>
> >          We implemented StuckThreadDetectionValve in server.xml( <Valve
> >
> >     className="org.apache.catalina.valves.StuckThreadDetectionValve"
> >
> >     threshold="60" />), but it  could not help out.
>
> Why not? Again, this suggests that long running threads aren't the problem.
>
> >        So we implemented custom StuckThreadDetectionValve by extending
> > StuckThreadDetectionValve from
> > catalina, it only goes to "constructor","initInternal",and in
> "invoke"(when
> > action fires), it does not go to function "getStuckThreadNames()" even
> > after threshold time.How to achieve the same.Is there any way to detect
> > stucked thread and kill them?
>
> First of all your invoke() method fails to call super.invoke() so the
> Valve is never going to do anything.
>
> Secondly, if the original valve didn't work adding a bunch of
> System.out.println() lines isn't going to magically make it work.
>
> Thirdly, getStuckThreadNames() is never called by any Tomcat code so it
> is no surprise that you never see a call to that method. That method is
> intended for use via JMX.
>
> I suggest you start again and tell us more about the problem you are
> trying to solve (lack of response) and your configuration. In particular
> we need to know your connector configuration and how users access the
> application. Do they connect directly to Tomcat or do they go via a
> reverse proxy?
>
> Mark
>
>
> >
> >   My custom Valve is like following :
> >
> > public class StuckThreadDetection extends StuckThreadDetectionValve
> > {
> > StuckThreadDetection stuckThreadDetection;
> >
> > public StuckThreadDetection()
> > {
> > System.out.println("in StuckThreadDetection constructor");
> >
> > }
> >
> > public void invoke(Request request, Response response) throws
> IOException,
> > ServletException
> > {
> > System.out.println("in invoke...");
> >
> > getNext().invoke(request, response);
> > }
> >
> > @Override
> > protected void initInternal() throws LifecycleException
> > {
> > System.out.println("In initInternal");
> > super.initInternal();
> > }
> >
> > @Override
> > public String[] getStuckThreadNames()
> > {
> > System.out.println("in getStuckThreadNames...");
> > String[] listStuckedThread = this.getStuckThreadNames();
> >
> > for (String threadName : listStuckedThread)
> > {
> > System.out.println(threadName);
> > }
> >
> > return listStuckedThread;
> >
> > }
> >
> > @Override
> > public String getInfo()
> > {
> > System.out.println("In getInfo");
> > return super.getInfo();
> > }
> > }
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
*Thanks & Regards,*

* Yogesh Patel*

Reply via email to