-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 3/5/14, 3:32 AM, Mark Thomas wrote: > On 05/03/2014 01:50, Christopher Schultz wrote: > > <snip/> > >> When I run under Tomcat 8.0.3, a couple of the images are >> loaded, and then the whole ... thing ... just ... stops. If I >> watch my log4j log file, every so often a flurry of activity >> occurs: several pieces of information are actually fetched from >> the database, and progress is made. But I have waited like 10 >> minutes and the series of requests never finishes in that time. > > I'd suggest compiling 8.0.x from trunk as that is now using the > released DBCP 2.0 and Pool 2.2. There was a pool issue (POOL-248) > that was fixed after the 8.0.x release that might have caused > this. I was thinking about that last night. I also saw the commit that upgrades to the DBCP2 release version, which was what really triggered that thought. Can you point me to the JIRA issue you were specifically thinking could be what I'm encountering? >> (Something odd I can see: when that small amount of progress is >> made, the idle connection in MySQL *remains* idle. The only >> conclusion I can come to is that a new connection is being >> created to fetch that data and then it's being dropped, or that >> something is giving up somewhere without telling me. Neither >> conclusion makes much sense. I haven't actually confirmed that >> any real progress is made... just that I can see "loading XYZ >> from db" in my log files... those messages are logged *before* >> the data is loaded so I don't know it has been at this point). > > Take a look at the pool with JMX. Again, if you work with trunk > you'll get lots of detail of exactly what each connection is > doing. I'll do that. > >> Thread dumps show that everything is waiting on: > >> - org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection() >> @bci=55, line=1385 (Interpreted frame) > >> It's not that large a number of threads. It's something like >> 30-40 threads waiting on connections. (I'm not entirely sure why >> there are so many threads active... I'm the only one using this >> environment and I made a single top-level request... I thought >> most browsers limited their outgoing connections to something >> like 8 per hostname, but that appears not to be the case). > > While that doesn't rule out a DBCP issuee, it does suggest that > there is at least something else going on that you need to get to > the bottom of. I need to re-run the test again, but I have a new theory after watching nothing but the log files and the number of stuck-threads in jstack on my previous run: Firefox is giving-up on the connections that never returned any data and closes them, making new requests to take their place. My evidence is that when the "primary" request completes (that's the one that generates the HTML page that requires follow-up resources), only a few threads get stuck (immediately). After some time interval (exactly 5 minutes), I get another flurry of "Loading data" lines in my log file and another set of threads gets stuck waiting on a connection. >> My DataSource configuration: > >> <Resource name="jdbc/diagnosis" description="JDBC connection to >> main CHADIS database" auth="Container" >> type="javax.sql.DataSource" maxActive="1" maxIdle="1" >> maxWait="10000" url="[url]" username="[user]" password="[user]" >> driverClassName="com.mysql.jdbc.Driver" removeAbandoned="true" >> removeAbandonedTimeout="30" logAbandoned="true" >> testOnBorrow="true" validationQuery="/* ping */ SELECT 1" /> > >> Note that I have a single database connection in the pool. > > Not with DBCP 2 you don't. maxActive has been renamed to maxTotal > so you'll have the default (8 from memory) connections in the pool. > This is likely to be a common problem. We probably need to add > something to catch this, report a warning and set the correct > attribute. Okay, I'll take a look at that. What I can observe practically is that only a single connection to my MySQL database has been made, whatever the reason. Perhaps that's part of the trouble. > You can also drop the validationQuery. DBCP2 will use isValid() > which is just as fast and frequently faster. Okay. For my remaining tests, I'll leave things alone. (Why would isValid be better? Is it because the driver itself can determine the fastest way to test the connection's validity? For MySQL, the /* ping */ in the validationQuery gets the job done without issuing the query at all, which is nice.) >> It looks like DBCP2 is kind of hosing, here. > >> I don't have a simple test case right now, unfortunately, but I >> do know that it has worked every time (maybe a dozen times) >> under Tomcat 7.0.47 and failed every time (maybe 5 times, now) >> under Tomcat 8.0.3. > >> I'm going to try using tomcat-pool to see if it makes any >> difference. I suspect it will, since they are completely >> different architectures.= > >> Any suggestions? > > - Fix the config I'll try this first just to see if it helps. I suspect not, as I was only seeing a single connection, anyway. I'll let you know. > - Switch to a trunk build I'll definitely do that. > In terms of performance, I've been looking at DBCP2 vs tomcat-pool > using the unit tests in tomcat-pool and there is a 10 to 20% > performance difference (tomcat-pool is faster) but when you look > into the why, the difference is pretty much entirely explained by > the extra default features in DBCP (like calling clearWarnings() on > a connection when it is returned to the pool). > > When you are talking about a test that performs 100,000 checkouts > and returns in 4s or 5s you quickly realise the performance > difference is likely to be in the noise once those database > connections start doing some real work. Yup. I've never been tempted to switch to tomcat-pool "for performance reasons" since DB queries themselves are so long-running (comparatively) that saving a few ns in the object synchronization, etc. hasn't been a priority for me. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTFyjfAAoJEBzwKT+lPKRYVw8QAItQSG5N5MTiy0CUE0bj7YKF EOwgLTAkrO7bfOw1cElH+u0dvJptIhrmsAAjm4HJk8cu3Ua75A/B025wrp8yhq+a mZFmNBfrYYARPWyr1vdDmt8V/sTY0UY4DrP8fp3ubR5Z6JcuHMrTBB/uIdfGTR9J ZkpF6JDnFCFMi3wcO0V7Ki775NZ+aNj78Ti5anYQYfX+aqUXY/ESozDznGelwEnE FwxjeEimQvCOtGtN+YeK8bQOAIxna/BJWn03GmI3Xo8OC/764dPI4uCrMkWAhvOh CY7thtOD6hwGOYPkTVfImV2LU8KQ9b6foLyjT5LKLfVE7a/CX+29ZCplFErMS0Gx px1uLDtpfZKsKxEYCoR0A+5XgrIXZaZ+9fgHsuWDYBauU1nPv//3gb5AzRmZFx4l lt5I/guWlRincELovQ8oos/2lkG3AvRV4GsgQiDGX9Hr5Z1gpENM12hMp0SoaeqX WXrIW+uuq0oM8ISjhFB2fsSQro6NKFhB/ev3Bm/9yJMH0yW7/3Rgv8um5SFxyieI rt3G6yAM0z30+jgybcX3+EtMbs+MQKS6Bct1K2tK1cpsHozAtIggEylUWKgfO+no u8a8f0roWuwpFhe8bP5SzC1Ww6tgLKhnhFU46YIuNG31mhQImYEwgmMGj+wkQFL/ grTQ0S1zIOaJZx9xundT =xvm5 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
