Yes, it does make sense, thanks for the advice. Unfortunately it didn't work out for me so well, issue continues to persist, connections are being created for the validation query and they are never released. Last time it got up to 80 idle connections used by the query. There must be something about JDBI3 I don't fully understand - I set maxSize to 32 and it still somehow manages to get to 80 connections. I'm using the default configuration now, but without success.
I would appreciate it if someone could point me in the right direction. Thanks, R. On Sat, Jun 8, 2019 at 7:06 PM Oscar Nalin <[email protected]> wrote: > I'm fairly sure that this line in your configuration file is what causing > your problem: > > checkConnectionWhileIdle: false > > Your connection pool will thus have this configuration (your conf. + > default values): > > checkConnectionWhileIdle: false > checkConnectionOnBorrow: false > checkConnectionOnConnect: true > checkConnectionOnReturn: false > > This means that the only time a connection is validated is when it is > added the first time to the connection pool. When the connection pool > validation runs every 30 seconds (default value), it will not validate your > idle connections. > > I think what is happening is that when you are requesting a connection > from the connection pool, the pool will consider your 8 connections dead > and thus will create 8 new ones and return one of them yo your application. > These are the 8 queries you are seeing, when the connection pool is adding > new connections to the pool. > > So to conclude, try to have checkConnectionWhileIdle: true (default > value), and see if that helps. > > Does that make sense? > > Den lördag 8 juni 2019 kl. 17:13:46 UTC+2 skrev Radomir Djurdjevic: >> >> Hi, >> >> Here is the section of configuration.yml relevant for the database >> (access data excluded): >> >> database: >> driverClass: org.postgresql.Driver >> >> # the username >> # the password >> # the JDBC URL >> >> properties: >> charSet: UTF-8 >> >> maxWaitForConnection: 1s >> # validationQuery: "/* MyService Health Check */ SELECT 1" >> >> validationQueryTimeout: 3s >> minSize: 8 >> maxSize: 32 >> checkConnectionWhileIdle: false >> evictionInterval: 10s >> minIdleTime: 1 minute >> >> I have commented the validationQuery property, so the default value is >> used. >> >> Small correction from my side: the validation query runs *8 *(not 10 as >> I mistakenly said before) times, which equals to *minSize* property. >> These connections are created on application start, but also then every >> time a new HTTP request comes in which uses some of the generated JDBI >> DAOs. All validation queries are switch state quickly to idle but are not >> cleaned up. >> >> I am tempted to set up Hikari connection pool, but seeing that other >> queries seem to be closed properly and only the validation query is an >> issue, I would rather resolve that first before inserting an additional >> component to the system. >> >> I appreciate the feedback. >> >> Regards, R. >> >> On Sat, Jun 8, 2019 at 4:26 PM Oscar Nalin <[email protected]> wrote: >> >>> How is your connection pool configured? Can you post the configuration >>> values you are using? >>> >>> The validation query that you are seeing is the default one. Look at the >>> java docs to see all default values: >>> https://www.dropwizard.io/1.3.12/dropwizard-db/apidocs/index.html >>> >>> Is the validation query running 10 times when the connection is created >>> or when you are requesting a connection from the connection pool? >>> >>> Den lördag 8 juni 2019 kl. 02:45:34 UTC+2 skrev Radomir Djurdjevic: >>>> >>>> Is there a way to get this default liveness check under control >>>> somehow? It is taking up space from regular clients trying to connect... >>>> >>>> On Saturday, June 8, 2019 at 2:35:29 AM UTC+2, Ryan Kennedy wrote: >>>>> >>>>> I believe this is the default liveness check for the connection pool >>>>> to determine if a connection in the pool is still “good” or not. >>>>> >>>>> On Fri, Jun 7, 2019 at 5:30 PM Radomir Djurdjevic <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> I have an issue with a health check query that appears approximately >>>>>> 10 times each time connection is established, although I've never set >>>>>> this >>>>>> check explicitly. It's the validation query: >>>>>> >>>>>> /* Health Check */ SELECT 1 >>>>>> >>>>>> In the *config.yml* I use for running the service there is no >>>>>> *valiidationQuery* property set, which makes me wonder where is this >>>>>> health check coming from. I do not have any other health checks put in >>>>>> place, so it can't be coming from the *health* module. >>>>>> Does anyone have an idea what could be making the health check? >>>>>> >>>>>> I am using: >>>>>> >>>>>> - Java 8 >>>>>> - PostgreSQL 11 >>>>>> - DropWizard 1.3.5 >>>>>> - JDBI3 >>>>>> >>>>>> >>>>>> Thanks a lot, >>>>>> Rasha >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "dropwizard-user" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/dropwizard-user/237a3003-1430-4468-a4e3-5bcbdaa4cd74%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/dropwizard-user/237a3003-1430-4468-a4e3-5bcbdaa4cd74%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "dropwizard-user" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/dropwizard-user/8f16d874-8335-441a-9638-4eee74382057%40googlegroups.com >>> <https://groups.google.com/d/msgid/dropwizard-user/8f16d874-8335-441a-9638-4eee74382057%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "dropwizard-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dropwizard-user/dd4422e7-8065-4268-b19f-6570eba4333b%40googlegroups.com > <https://groups.google.com/d/msgid/dropwizard-user/dd4422e7-8065-4268-b19f-6570eba4333b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dropwizard-user/CAHq0KsaUReJTr8%3DTxAYMxMX0-_-ixSwQPacHAFFq9vhLtO2%2BSA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
