-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/03/2014 13:38, Christopher Schultz wrote: > 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?
POOL-248. >>> (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. Hmm. I don't recall exactly when this was renamed in DBCP 2. It is always possible the build you are using does what you think it does. >> 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? Yes. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTFy0NAAoJEBDAHFovYFnnAwsQAPeHLWrK5Q8uANmrxqau+9/y rLkiODMTXPDvQbqod2AavqKKX+uLGQzyEI2mw4svuE+rca0Q37TfXNGsfK9F6u3x NzJl91VaXOyT/3fuHfGeYHWmwdM1uT1QrK8ISRmf0eZEN9YSqk96rPnx/iB1UvYz lxCbzndn5qVxwz/t1gMhW9WYTYGNQpMnFUtMt+G1m/yQ+uSs0kN1v5Ns6ppK8Q3S RizQYWrUr8P1K/IsmuVnWOBLuNJJxaufGa3C3T6qFumGSDibiTgR/NwMeVpZ3JIa r8t0XJrDZBw4MJqS2I2ns9sYeBecCbUn5EvAp5VDOTBoGmagk6ZBJOschREw8NFb 6VFx3Ke0cH4dL8baEybSr4a/lMeg6uX12nwkLVWHu0ZWkgOqRD1VWBGqWj5JN1eK 761WtLzPsEw2EzpzoGfuT2EEuK1Iq0FQTbmfbffJLgNHZ4u9HX0hRxIpIAfU+ThH /8WazFGKORQt44pVFK5JyZ3h7iqN7M/hawcYl+JgePzhokYgRae8hYGDJLLihHlp 8KYgMk0IDRSCcp4CTmvDjKlq4CcLfpI6sUSNu6AS5Xv9XowOM+F+83V0lzZtCFoU kY0k2j8kwDS51dFMXws6VZOyqos2gQpSvK/VL+Ku5xaxeNbAEHYLhW0X7wCRsssD 6ihY3xEhdBJt2e2PTisJ =CB4N -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
