-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > (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. > 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. > 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. You can also drop the validationQuery. DBCP2 will use isValid() which is just as fast and frequently faster. > 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 - - Switch to a trunk build 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. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTFuEYAAoJEBDAHFovYFnnqHoQALvntENdBi2dJBqiZvAR6pYA eYbWWMQZz/qy7WoCtuzR9gmBj51WpXB6fLGpd+nIWcU2p2I4GO6CugL+G2Pmulxd dcSxSV0hwFK7qTSvnmzzEN4EN7hIbiV9AyP3uMvJADwo7stwY9OWQN+jiXPksWRH 5tQ52ZYF807RcCcvdNKp4yAudod9vn4hroMR/Bt8mQ72y7WzEbyHVSgLuARWnCcu bPBSJwLFZ329oqNXRFuf3JTk4hH8H2KlPB5BLQLeVI56bA+HcpwsjzPxU5YrqZdb Jj0brLigh3ReEfL1SwmaDGmo5kMUBDS5JNjtXXTmd43PX8wO6OeuwY82Q83iCWK+ WMksIdpIb7MdE8VNfmWHHzRQMfskEGd96HVJMG4ALnr1ZBhnEPorHlGeA02tdiER 7P5/3RUbTvNRPCV0ktDkvWgn87WJ+3MTO6uJl7zBuCjg0UU59eydXFk31s0u5I3q u1310TsWTuKLtqTPU5yuhSxLynizdlKClAA9x8xuY/0V3UeBNZdsBDm3tCrwXwBU wrkVy45W2rcmd0OYQpVJE4F43p1SiY2s6fX9inilju7T4be/aElEeVrDUBaude1P dsrqNbQFofsys4jRs+MuE2HJ+NbKypeIitr+9TunSSNdvBJDSZvUWXmICY65r19g 96rGnU4v4p2tbiaYZ9nA =X7lB -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org