On Tue, Feb 13, 2024 at 1:03 PM Bernd Eckenfels <e...@zusammenkunft.net> wrote:
> Phil Steitz wrote on 13. Feb 2024 20:46 (GMT +01:00): > > Thanks, Gary. I agree with everything below. I think it's best to just > > leave things as they are. > > If it’s plugable the project might not have to care, > But then how to fix the reported problem? Do we have an idea what’s > causing it? > At this point, my best guess is that the app is not closing connections on some exception paths. Given that force-killing connections that will get killed anyway on return improves the situation supports that idea, but I have not dug into the application code. > > And a extension to that, using a conn3crion pool you expect it abstracts > and handles all > Those idiosyncrasies of different drivers, platforms and JDBC > interpretations. Just giving > Up is not the best option. > We decided years ago that we were not going to try to add special code for every driver and I think that is a good decision. The code is already plenty complex. I think the solution implemented now to fast fail validation in this case is sufficient. I don't think waiting to close until the connection is returned is actually causing the reported problem. > > In my experience with a properitary (but very robust pool since it handles > a small number of drivers) > throwing away connections on concrete suspicion turned out to be helpful. > Either by configurable state, substrings of error messages or actual > sqlexception subtypes. > > But maybe additional validation is also fine as long as it uses strict > timeouts, some control for paralysis and starvation. If I understand this > would happen in the mentioned problem case, so is there a timeout missing. > > Having said that as a tip to OP use tcpkeepalive and lower the timeouts. > It saved my ass more than once, especially with VIPs in place. > The liveness problem is a [pool] concern, per my recent post. I think getting support in [pool] for managing transient factory outages would really help. Any ideas that you have on how to do that would be much appreciated. Phil > > Gruss > Bernd > — > https://bernd.eckenfels.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
