Chris, On Fri, Feb 2, 2018 at 2:20 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > On 2/2/18 1:47 PM, Pawel Veselov wrote: >>> On 2/1/18 6:08 PM, Pawel Veselov wrote: >>>> On Thu, Feb 1, 2018 at 1:02 PM, Mark Thomas <ma...@apache.org> >>>> wrote: >>>>> On 01/02/18 20:57, Pawel Veselov wrote: >>>>>> Hello. >>>>>> >>>>>> It looks like in tomcat 8 (looking at master's HEAD), the >>>>>> minIdle support is broken. According to docs, minIdle >>>>>> supposed to do : "The minimum number of established >>>>>> connections that should be kept in the pool at all times. >>>>>> The connection pool can shrink below this number if >>>>>> validation queries fail." >>>>>> >>>>>> I see that pool cleaner thread checks if the minIdle is >>>>>> *less* than pool size, and only then invokes checkIdle(). >>>>>> checkIdle() then will remove(!) connections from idle pool >>>>>> until the value drops down to minIdle. But I don't see any >>>>>> code that will add connections when minIdle is not met, and >>>>>> the documentation suggests that that's the intent. >>>>>> >>>>>> Am I misunderstanding something? Is there a way to keep a >>>>>> level of connections in the pool? I don't want to have >>>>>> initialSize control that, as I need to at 0, to prevent >>>>>> failures during pool initialization... >>>>> But that is what initial size is for. >>>> Indisputably so. However, that would be the only other way to >>>> achieve this, as long as the database connection don't die.
I apologize, I actually misread what Mark has said here, reading the exact opposite of what he wrote. Have I read it correctly, I would have phrased my response differently, though I don't think that there is a difference at this point in this discussion. >>> What is the problem with failures during pool initialization? >> ConnectionPool.init() attempts to borrow initialSize worth of >> connections. Imagine your database server is having problems at >> this time. This will make init() fail, and the pool creation fail, >> and your webapp is dead in the water after that > Is it? Does init() in fact fail? Which pol are you talking about? org.apache.tomcat.jdbc.pool.ConnectionPool. And actually, it doesn't. I'm sure it did at some point before, that's why I set initialSize to 0 (it's an old application), but I tested it on 8.0.49 and in 8.0.9 just now, and the pool does come up and binds. So this is a non-issue. > If your webapp needs the pool to be working on startup, then delaying > the pool-initialization until "later" will only delay it a few ms. The point here was that I either have an existing pool with no connections, rather than no pool at all. >> it's unlikely that there are mechanisms to attempt to recreate the >> connection pool. > The connection pool is just fine. It just doesn't contain any connection > s. Right. Again, I had an assumption that initialization failed, otherwise my point had no sense. >> This complicates automatic recovery. An existing pool can recover >> easily, once the database is back online after a failure, the >> connections will be vended normally. > I would expect that any pool would recover when the database becomes > available again, regardless of when the first connection was attempted. Same here. >>> If you don't want the pool to make initialSize connections when >>> it starts, when DO you want the pool to create those connections? >>> During the first "cleaning"? >> I don't have strong expectations on exactly when the pool is to be >> inflated. minIdle suggests that it should happen at some point, may >> be that can be "cleaning", though this thread should probably then >> be renamed as "maintenance". If not inflated in time, then any >> requested connection will populate the pool, that's already what >> ends up going on in my case. >> >> In all cases, I think that either minIdle should be reimplemented, >> or at least the documentation should be changed from saying "The >> minimum number of established connections that should be kept in >> the pool at all times" to "Minimum idle connections that will >> remain in the pool after cleaning", with a note that idle >> connections are not created by the pool itself to fulfill that >> amount. > This may simply be an issue of semantics. When I read "min idle", I > have no expectations that the pool will pro-actively create new > (idle!) connections just to put them into the pool. As Mark said, > that's what "initial size" is for. I'm merely following the wording used in the documentation. I have quoted the language used in the documentation, and there is no conditional statements that the new connections will not be created to satisfy minIdle. To rephrase what the docs say now : "the number of the idle connections in the pool will *always* be at least minIdle, unless validation fails". Removing the "at all times", and adding a statement of "connections will not be created to satisfy this value" seems to be a resonable remedy, if you believe that the current algorithms is what you, in fact, want. >> The reason prefer the pool to auto-saturate, is that so sudden >> demand for high amount of database connections doesn't require a >> lot of new connections to be established, as that's the slowest >> part of the process. > > Sorry, you can't have it both ways: don't create connections in > advance, but create connections in advance "just in case". What you > are describing is what I call "do-what-I-mean semantics" which means > that you (YOU, a human) always "know what you mean" but you can't > articulate the heuristic that you use to make decisions in any way > that can be programmed. (This is a favorite requirements-model of > Marketing, Design, and Sales teams.) I disagree. I said, to rephrase, - "don't create connections during initialization", not, to rephrase, - "don't create connections in advance", which is different, and not just semantically, and I previously explained why it was important (because initialization could fail, or I believe it could fail). And to conclude all of the above: * right, so there is no problem with the initialization (may have never been, but this app was written in times of Tomcat 6). So I can restore having initialSize to match minIdle. Great. * Separately, I believe it's prudent to address the fact that documentation doesn't agree with the implementation, that's for common benefit. That may be subjective, but it's probably easier to add statements that clarify the implementation, rather than having users misunderstand that. * I also still believe that having the pool to create connections to catch up to minIdle is actually a "good thing", because that allows to have pools that have a ready capacity, even after a database failure. At this point, there is no way to achieve that. It can, of course, be argued that this is an unnecessary marketing feature. Thank you, Pawel. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
