-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kaleb Pederson wrote:
> Hello,
>
> I have an interesting problem. After a while, tomcat (5.0.27) becomes almost
> completely non-responsive. If I telnet in to port 8009 (I'm using apache
> and mod_jk2), I get no response, at least not within the default timeout. If
> a browse to a page, I will generally, after about 4-5 minutes, see a page
> returned.
>
> To narrow down the slowness, I generated a full thread dump, and found the
> following information:
>
> [ see attachment for more info]
> Total threads: 180
> executeQuery: 2 // executing a db query
> validateConnection: 0 // trying to validate their connection
> validateObect: 48 // in commons.dbcp.PoolableConnectionFactory.validateObject
> socketAccept: 3 // accepting a socket
> socketRead0: 10 // reading a socket
> ReferenceQueue: 1
> ThreadPool$MonitorRunnable: 2
> borrowObject and Object.wait: 85 // trying to get an object from the pool
> Object.wait: 20 // threads just waiting around
> Remaining: 9 // misc. threads
>
> My database connection is setup so that I have 50 allowed connections, which
> matches my 48 in validateObject and 2 executing queries. However, when I
> query the database status, I see 2 active threads and the rest are
> 'sleeping', just waiting around, as they would be if the connection pool
> hadn't released them yet.
>
> So, why would there be 48 connections that seemed locked and weren't querying
> the DB? And then the other 85 that were seemingly waiting on the 45? Any
> ideas what might be going on? The DB is ready? I have log abandoned turned
> and an haven't seen a problem yet. If the load drops sufficiently on the
> server, everything eventually returns back to normal, otherwise it takes 5-10
> minutes to get a response from the server.
>
> I have attached an abbreviated form of the thread dump which should provide
> all the critical information and can provide as much other information as is
> necessary.
>
> Thanks for the help. *All* suggestions welcome ;)
>
> --Kaleb
>
>
> ------------------------------------------------------------------------
>
> Total threads: 180
> executeQuery: 2
> validateConnection: 0
> validateObect: 48
> socketAccept: 3
> socketRead0: 10
> ReferenceQueue: 1
> ThreadPool$MonitorRunnable: 2
> borrowObject and Object.wait: 85
> borrowObject: 0
> Object.wait: 20
> Remaining: 9
> ***************************************************
> 2 like "TP-Processor296" daemon prio=1 tid=0x6ea04a90 nid=0x5e87 runnable
> [738f6000..738f787c]
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
[snip]
Kaleb,
Looks like you're using an old version of the JDBC driver that uses
BufferedInputStreams by default. There is a 'feature' (many call a bug)
in BufferedInputStreams that causes them in some cases to want to read a
full buffer's worth of data when you're only asking for some portion of
it...That's what's happening here.
I'd try downloading something more recent for a JDBC driver (like
Connector/J 3.0.15) and see where that gets you, to start with.
-Mark
- --
Mr. Mark Matthews
MySQL AB, Software Development Manager, J2EE and Windows Platforms
Office: +1 708 332 0507
www.mysql.com
MySQL Guide to Lower TCO
http://www.mysql.com/it-resources/white-papers/tco.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBY1AztvXNTca6JD8RAvEIAJ4p5Fi9QIwhNTlNslLMW6cKGhmUpgCeP2JJ
RurwXfMfDzSEGTRLqssk4b4=
=s3u9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
