On 8/1/15 6:14 PM, Christopher Schultz wrote: > Phil, > > On 8/1/15 11:12 AM, Phil Steitz wrote: > > Sorry the docs are not that clear. The problem is that the config > > properties work together to determine behavior and documenting > > them individually makes it hard to put the whole picture together. > > Improvement patches most welcome :) In any case, here is how it > > works: > > > Connections are evaluated for abandonment when they are out in > > circulation - checked out to clients. If you have set > > timeBetweenEvictionRunsMillis to a positive value, pool > > maintenance runs every timeBetweenEvictionRunsMillis milliseconds. > > If you have removeAbandonedOnMaintenance set to true, each time > > maintenance runs the pool removes abandoned connections. If you > > have removeAbandonedOnBorrow set to true, the pool removes > > abandoned connections if it is nearing depletion when a borrow > > request arrives. In both cases, the pool looks at the statistics > > that it maintains on the list of all objects checked out by clients > > to determine which ones appear to be abandoned. To appear > > abandoned means to be checked out by a client but not used for > > longer than the removeAbandonedTimeout. For DBCP, "used" means the > > connection has been used. > > So when during all that does the abandoned connection get "logged"?
The log message is written when the abandoned connection is closed by the pool. (The pool bug was basically delaying the effective write; but the stack trace goes to the buffer when the close happens) > > If I have a pool with two connections in it, and the first one gets > leaked (after, lets say, 10 seconds) but the second one is returned > properly, and the application continues to borrow and return the > second connection, what happens? That depends on the settings. See below. > > Are you only checking connections for "abandonment" after they are > returned and then when a client attempts to borrow that specific > connection? Or, are all currently-borrowed connections checked for > abandonment whenever any borrow operation is requested? It is the latter, assuming removeAbandonedOnBorrow is true. Removal on borrow also requires that the pool be near depletion when the borrow happens (see the javadoc for precise description of conditions). There are two things that can trigger abandoned object removal - a borrow request and pool maintenance. In each case, if the config setting to enable the check on that event is on, all checked out objects are examined. The ones that appear abandoned are destroyed (in DBCP that means physical connections are closed). Phil > > Thanks, > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
