Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 5256 invoked from network); 22 Dec 2010 17:29:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 22 Dec 2010 17:29:59 -0000 Received: (qmail 26491 invoked by uid 500); 22 Dec 2010 17:29:55 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 26429 invoked by uid 500); 22 Dec 2010 17:29:55 -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 26420 invoked by uid 99); 22 Dec 2010 17:29:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Dec 2010 17:29:55 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [76.96.27.228] (HELO qmta15.emeryville.ca.mail.comcast.net) (76.96.27.228) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Dec 2010 17:29:48 +0000 Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta15.emeryville.ca.mail.comcast.net with comcast id mGna1f00316AWCUAFHVTkl; Wed, 22 Dec 2010 17:29:27 +0000 Received: from [192.168.1.201] ([69.143.109.145]) by omta06.emeryville.ca.mail.comcast.net with comcast id mHVR1f00738FjT18SHVSE8; Wed, 22 Dec 2010 17:29:27 +0000 Message-ID: <4D123575.9060208@christopherschultz.net> Date: Wed, 22 Dec 2010 12:29:25 -0500 From: Christopher Schultz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tomcat Users List Subject: Re: Tomcat Hangs with variable frequency References: <248956.54627.qm@web121205.mail.ne1.yahoo.com> <770996.47177.qm@web121205.mail.ne1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin, On 12/22/2010 11:56 AM, Konstantin Kolinko wrote: > If closing the result set requires reading it in full (as JTDS does), > it can take significant time. Especially if the queries are something like SELECT * FROM huge_table > You should take thread dumps to see what the threads are doing and > what they are waiting for. (Three thread dumps taken several seconds > apart). I would also inspect the queries that are in progress when these connections appear to hang. We had a problem with Oracle long ago where the table indexes had just become horribly fragmented and performance slowed to a crawl. In an act of desperation, someone ran "OPTIMIZE TABLE" on one of the tables involved in particularly slow queries and basically everything got better. From then on out, we called that "turning off the 'suck' bit" on Oracle. :) I would definitely like to see what queries are running on the server and what their status is. The problem is certainly /not/ Tomcat, here: threads are stuck in a 3rd-party library connecting to a 3rd-party database. Tomcat just happens to be in the stack trace because that's the DBCP in use: the driver appears to be hanging, not Tomcat's DBCP. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0SNXUACgkQ9CaO5/Lv0PDAUQCfWgdgZY61qly2Z0xDP4vhZcbX OyYAn14lv4chUAmiD4h4z3jqgDPxOGda =Fqs8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org