I've went through the list and pretty much the only ticket which was left to really benefit from it would be the getMaxNumActive() (POOL-355). But as noted there: after a bit of thinking through it I'm even tempted to close it as won't fix. Having just a bare maxNumActive doesn't give you much info in real production. What you need is really a time graph with the currently active connections. You usually don't care about just a short spike e.g. because the underlying db gets restarted. What you care about is whether the connections are fine NOW and at which timeframe they have been in a bad shape.
If you (and others) could also take a look on this ticket them we could go on and close it. Which whould then remove the need for Java8. That means I'm perfectly fine with keeping it java7 for now. Plus we also know what to take care of if we really need to bump to j8. LieGrue, strub > Am 29.10.2018 um 09:35 schrieb Mark Thomas <ma...@apache.org>: > > On 28/10/18 11:09, Mark Struberg wrote: >> Hi folks! >> I've worked through the open POOL tickets and found a few tickets which >> would like to enhance a few of our interfaces. >> E.g. in POOL-355 we have a request to add a new method getMaxNumActive() to >> the ObjectPool interface. >> Now this would of course be a backward compatibility breaking change. If we >> would have java8 as minimum then we could easily just add a default method >> which returns -1. But since our min Java version is 1.7 we are doomed... >> I would love to get the deadlock fixes out with the current 1.7 requirement >> first. Because that's important to get to the people (including my own >> customers). >> But what after that?Would this justify a commons-pool-3.0?Do we also like to >> cleanup other stuff? Or should we just raise our min Java requirement to 1.8 >> and call it 2.7? >> I'm totally fine either way and would love to get any feedback. > > Tomcat 8 (with a spec required minimum Java version of Java 7) is > currently using the latest version of pool. This version of Tomcat is > unlikely to be EOL until well into the 2020s. It would be easier if pool > stayed on Java 7 (since we maintain a package renamed copy of the code) > but I appreciate that that is not practical for pool for that timescale. > > It isn't a huge amount of work to handle things like default methods. > The Tomcat community would certainly appreciate it if any Java 8 > specific changes in Pool kept in mind that Tomcat will need to back-port > them to Java 7. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
