Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B495863DC for ; Sat, 11 Jun 2011 17:23:59 +0000 (UTC) Received: (qmail 5394 invoked by uid 500); 11 Jun 2011 17:23:56 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 5356 invoked by uid 500); 11 Jun 2011 17:23:56 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 5347 invoked by uid 99); 11 Jun 2011 17:23:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Jun 2011 17:23:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of afkham@gmail.com designates 209.85.161.173 as permitted sender) Received: from [209.85.161.173] (HELO mail-gx0-f173.google.com) (209.85.161.173) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Jun 2011 17:23:49 +0000 Received: by gxk26 with SMTP id 26so3453746gxk.18 for ; Sat, 11 Jun 2011 10:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=dXm/tqZBIeHOf8f5CPxBd1Na2vpw02BWvzFSndIlvzM=; b=EugsnpMOiyVAumR41hIX71ShWY5GE4r7n7IP1AxoC4BU4Fw0ojYV9OTL9jOKwZvhNn kaZvVrFk6zI7iO9xYGzBNYQqvU1CXzWVpo+lf4SVn7CrTR6c+pCIvF/xo6zxBMBem7W/ /f1aRGWJHbewsUrmdardSk+hP9aBvB9X41/MQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=LFSBJ/NkCZG5giQbHaDwgvNIZYypp09eL0bqaFBoUmMBt1CzZ98deuRnnC3y1F/yuR TkutqVYV6fG2Cmy3XIjduZ3or/oXFwF27eVdgfEXg4ZmNBW0cVEjLXyGYdDrGz9kGig+ i+6/XM1aoESJ/1zrnkzbgSjCSXgOfskGTarMU= Received: by 10.236.63.136 with SMTP id a8mr4870414yhd.339.1307813008125; Sat, 11 Jun 2011 10:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.202.41 with HTTP; Sat, 11 Jun 2011 10:23:08 -0700 (PDT) In-Reply-To: <4DF38598.3010702@kippdata.de> References: <99C8B2929B39C24493377AC7A121E21FAFF0860FA2@USEA-EXCH8.na.uis.unisys.com> <4DF38598.3010702@kippdata.de> From: Afkham Azeez Date: Sat, 11 Jun 2011 22:53:08 +0530 Message-ID: Subject: Re: Terminating long running request threads To: Tomcat Users List Content-Type: multipart/alternative; boundary=00248c6a8466c831be04a572f152 X-Virus-Checked: Checked by ClamAV on apache.org --00248c6a8466c831be04a572f152 Content-Type: text/plain; charset=ISO-8859-1 Thanks Rainer. I think I can use the RequestProcessor MBeans. Thanks Azeez On Sat, Jun 11, 2011 at 8:41 PM, Rainer Jung wrote: > On 11.06.2011 09:30, Afkham Azeez wrote: > > Folks, > > Is there any API to get hold of Tomcat's Connector thread pools? > > Each request is registered with an MBean in the MBeanServer. > As long as the request is running, the MBean contains additional info, > like the URI, when the request started, the thread name etc. > > This gives you enough info to find long running requests and to find the > thread. But there's no non-deprecated Java API known to have no side > effects to terminate a thread. If it were (or you find one), we had to > check how the thread pool behaves w.r.t. "vanishing" threads. > > Regards, > > Rainer > > > On Thu, Jun 9, 2011 at 10:58 PM, Afkham Azeez wrote: > > > >> > >> > >> On Thu, Jun 9, 2011 at 10:51 PM, Caldarale, Charles R < > >> Chuck.Caldarale@unisys.com> wrote: > >> > >>>> From: Afkham Azeez [mailto:afkham@gmail.com] > >>>> Subject: Terminating long running request threads > >>> > >>>> is there a way to get hold of these long running threads > >>>> & terminate them? > >>> > >>> This is not an issue specific to Tomcat; there is no way to safely > >>> terminate a Java thread without the cooperation of that thread. Best > if you > >>> can code your webapp so that your request processors periodically check > if > >>> they've been running too long and give up if so. > >>> > >> > >> Yes, it is not a Tomcat specific issue. The thing is, we don't have > total > >> control over what type of webapps will be deployed. We do restrict > certain > >> operations using a Java Security Manager, but I do not think we can > restrict > >> the running time of a Thread using a security manager. Using > >> the ThreadMXBean we can monitor the time each thread takes, and get the > >> thread IDs of long running threads. It may be possible to get that > thread to > >> terminate if we have some support for that from the Tomcat threadpool. > Just > >> thinking out loud. > >> > >> Thanks > >> Azeez > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > --00248c6a8466c831be04a572f152--