Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cloud-sql knex.js related example configuration is inconsistent/confusing #1697

Closed
nikosgraser opened this issue Apr 1, 2020 · 2 comments · Fixed by #1746
Closed

cloud-sql knex.js related example configuration is inconsistent/confusing #1697

nikosgraser opened this issue Apr 1, 2020 · 2 comments · Fixed by #1746
Assignees
Labels
api: cloudsql Issues related to the Cloud SQL for MySQL API. type: question Request for information or clarification. Not an issue.

Comments

@nikosgraser
Copy link

I'm coming from the GCloud Documentation's Managing database connections page about PostgreSQL and Node.js while trying to diagnose connection issues with a live Cloud SQL database.

The section on how to configure the Knex Client pool left me wondering in some places, however:

// 'createRetryIntervalMillis' is how long to idle after failed connection creation before trying again
knex.client.pool.createRetryIntervalMillis = 200; // 0.2 seconds

The explanation recommends implementing an exponential backoff, yet here we set a flat value. Does this mean that Knex cannot be configured to do an exponential backoff when acquiring connections?

Right below it, we have:

// 'acquireTimeoutMillis' is the maximum number of milliseconds to wait for a connection checkout.
// Any attempt to retrieve a connection from this pool that exceeds the set limit will throw an
// SQLException.
knex.client.pool.createTimeoutMillis = 30000; // 30 seconds

The comment describes acquireTimeoutMillis, yet in the code the createTimeoutMillis is set. Which one is right here? Does it make a difference, and if so, what is the difference?

Below, the code then actually sets acquireTimeoutMillis:

// 'acquireTimeoutMillis' is the maximum possible lifetime of a connection in the pool. Connections that
// live longer than this many milliseconds will be closed and reestablished between uses. This
// value should be several minutes shorter than the database's timeout value to avoid unexpected
// terminations.
knex.client.pool.acquireTimeoutMillis = 600000; // 10 minutes

acquireTimeoutMillis really does not sound like a "total lifetime limit", and indeed tarn.js (where the Pool implementation from knex.js is imported from) describes it like this in their documentation:

// acquire promises are rejected after this many milliseconds
// if a resource cannot be acquired
acquireTimeoutMillis: 30000,

What configuration option would actually give the described "total lifetime" functionality?

The relevant code pieces are all from cloud-sql/postgres/knex/server.js.
Could someone who is more familiar with the libraries and mechanisms at work here please look over the documentation and the code that goes with it?

Thank you!

@fhinkel fhinkel added api: cloudsql Issues related to the Cloud SQL for MySQL API. type: question Request for information or clarification. Not an issue. labels Apr 1, 2020
@shubha-rajan
Copy link
Contributor

After looking into this, it looks like the pool implementation isn't configured for exponential backoff. From what I understand looking through the tarn.js documentation createTimeoutMillis is the amount of time to wait while creating a new connection before cancelling and possibly retrying, while acquireTimeoutMillis would be the total amount of time to wait to acquire a connection from the pool. You're right that isn't really a "total lifetime limit". It looks like idleTimeoutMillis, which removes idle connections from the pool comes closer to that functionality.

@nikosgraser
Copy link
Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: cloudsql Issues related to the Cloud SQL for MySQL API. type: question Request for information or clarification. Not an issue.
Projects
None yet
4 participants