Ошибка resourcerequest timed out

const sequelize = new Sequelize('dbname', 'username', 'password', {
  host: 'example.rds.amazonaws.com',
  dialect: 'postgres'
});


sequelize
  .authenticate()
  .then(() => {
    console.log('Connection has been established successfully.');
  })
  .catch(err => {
    console.error('Unable to connect to the database:', err);
  });

Unable to connect to the database: { TimeoutError: ResourceRequest timed out
    at ResourceRequest._fireTimeout (myappnode_modulesgeneric-poollibResourceRequest.js:58:17)
    at Timeout.bound (myappnode_modulesgeneric-poollibResourceRequest.js:8:15)
    at ontimeout (timers.js:380:14)
    at tryOnTimeout (timers.js:244:5)
    at Timer.listOnTimeout (timers.js:214:5) name: 'TimeoutError' }

I cannot reproduce the error. Obviously there was a timeout in connecting to the DB server, it doesn’t look like a bug in Sequelize to me.

Tried the same endpoint and other credentials using pg-promise, and I was successfully connected. Could you tell what db server you tried it on? Of course, the app connects to my local db.

Own applications running on AWS that use Sequelize.
I am sorry, but even if you can connect with pg-promise, I have no way to find out why it wouldn’t work with Sequelize without a repro.

I have the same exact issue!

Same issue here. The connection is established but when the connection of any connection is lost, the pool is getting smaller and after death of all threads application goes down. We had no troubles with this with 3+ version of Sequelize, so I guess it’s not problem of db connection. Also tried downgrade from 4.2.1 (latest) to 4.1.0 and same problem.

I have fixed the issue by maximizing the acquire option of pool configuration in sequelize

pool: {
    max: 5,
    min: 0,
    idle: 20000,
    acquire: 20000
}

I guess Amazon RDS runs a lot of checks when asking for resources.

Also I am running the Free Tier of Amazon RDS.

I’m having the exact same issue! The above pool configuration did NOT work. In our production environment, in a 24h period this error is logged ~5,000 times. It’s been consistent for the last 27 days. I too am on the latest v4 of sequelize and using AWS RDS. It would be great to have this looked into more closely as it’s a serious risk in the latest release.

Yeah, I’m having this same issue on a DigitalOcean server as well. I’ve tried the configuration from above with no luck.

I am encountering the same problem on a DigitalOcean server. Do you have any updates on this issue?

I have also tried swordfish444 solution, but it didn’t work.

Cheers @philipdbrown for the solution. I have actually solved it in a dumb way by using setTimeout.
It’s not the most efficient method but it should do for now until they fix it.

thanks @afituri, your solution fixed the timeout error (for now).

just curious, in which case Sequelize can reach that options and get the TimeOut error again?

what are the «rare» and «optimal» options we need to set, to stay safe of Timeout error?.

i got Timeout error (with default pool options) just by quering 700 items (one by one) not everyone at the same time, but in the same proccess/thread.

what happen if y upload a massive excel with huge data to quering like 10k or more items?

Along with using long timeout and fix in #7924, this should be fixed

@sushantdhiman
After upgrade sequelize to v4.4.7, I still have the same problem.

@foisonocean hmm, any way to reproduce this ?

@sushantdhiman I’m using mysql, and when I insert 8000 items, I got this error.
By the way, when i connecting to my local mysql database, I also got the same problem.

@foisonocean you can see our CI works properly. If anyone can submit a proper failing test case I will try resolve this. I cant help if I cant reproduce this issue

I’m having this same issue and I want to give a PR to reproduce this issue but I can not reproduce every time! My test code like:

sequelize version: 4.4.3
posgrese 9.4.10
pool config {
max: 5,
min: 1,
idle: 10000,
acquire: 10000,
evict: 60000,
handleDisconnects: true
}

My reason fot this issue was unhandled transaction (make bunch of transaction, no commit or rollback).

I have a .txt file with 21497 rows and I read this file with fs.readFile and forEach row, I sync with Product table and insert the new records or update the existing ones.

A lot of records are inserted or updated on the Postgres database, but the major part I get this error:

If I try to run again on the same file, new records are inserted, but the error continues on other records.

Maybe it’s a lot of processing at the same time and some records are timed out. But how can I solve this? I tried to increase the max pool value but doesn’t work.

Suggest a bulk insert here, so instead of 21497 inserts it is 1 insert. I think method is bulkCreate or bulkInsert

…

Suggest a bulk insert here, so instead of 21497 inserts it is 1 insert. I think method is bulkCreate or bulkInsert

I found the updateOnDuplicate option on bulkCreate documentation, but it’s only supported by mysql.. so I don’t know how to use bulkCreate with the Upsert effect. Do you have any idea?
Thanks!

Are you using postgres? There is this:

PostgreSQL since version 9.5 has UPSERTsyntax, with ON CONFLICT clause. with the following syntax (similar to MySQL)

…

Having same issue. Using postgres 9.6

(node:61927) UnhandledPromiseRejectionWarning: TimeoutError: ResourceRequest timed out
    at ResourceRequest._fireTimeout (/Users/McFlat/indexer/node_modules/generic-pool/lib/ResourceRequest.js:62:17)
    at Timeout.bound (/Users/McFlat/indexer/node_modules/generic-pool/lib/ResourceRequest.js:8:15)
    at ontimeout (timers.js:466:11)
    at tryOnTimeout (timers.js:304:5)
    at Timer.listOnTimeout (timers.js:267:5)

Turns out Sequelize isn’t production ready yet after all. Doesn’t surprise me! Man will never be like the father in heaven, deny it all you want, but that’s the reality. youtube search «Shaking My Head Productions». Can’t depend on any of this tech crap, it’s all garbage from the devil himself, that’s the real nature of the problem if you think about it deep enough.

@lcandiago If I read your code correctly, you are syncing the Product model for every row, and you are actually running all queries in parallel. This is where your timeout comes from. Just put a console.log before const product = … and you’ll see what I mean. Your console.log will probably have time to execute 21497 before a handful of queries complete.

Sync your Product model beforehand and change your forEach for a plain old for loop such as this :

for(let i = 0; i < rows.length; ++i) {
   const product = {
      ...
   }
   try {
      await Product.upsert(product);
      console.log(...);
   }
   catch(...) {
   }
}

You will then run all queries sequentially and this should to the trick. You could try to run them in batches of 5, 10, 20, etc. to get better performance.

I’m experiencing the same issue started recently, MariaDB, sequelize 4.42.0, mysql2 1.6.5.

I just wanted to post this to potentially help anyone else out.. because I was really struggling with this myself and could not figure out why I couldn’t connect to the database on my server (ubuntu 18.04), but could in dev. Turns out, inbound rules on Amazon were set to a specific ip, and editing inbound rules to anywhere (any ip address), I wasn’t getting anymore connection timeouts. I thought I had set this up in the beginning because it’s a test project, but apparently not..

I had the same issue, but locally. Turns out I forgot to commit a transaction before returning a model instance.

For those of you still using v4 of Sequelize, this problem may have been fixed by v4.44.1.

See PR: #11140
See Issue: #11139

Still experiencing the bug on v4.44.1.

It might be worth just migrating to v5 and to see if it’s been resolved there.

Still experiencing the bug on v4.44.1.

It might be worth just migrating to v5 and to see if it’s been resolved there.

@Joshua-Turner are u successfully migrated to v5 and find everything perfect? Do you have any experience with the v5?

We have upgraded to v5 and seems like it helped for some reason. But it was such a shot in the dark.

We upgraded to v5 as well. With no further sequelize (i. e. pooling) configuration other than that, we still get SequelizeConnectionAcquireTimeoutError: Operation timeout. Anecdotally, this timeout-ing seems to occur less, but haven’t measured/monitored closely in our deployment.

Will update if we find a configuration or bugfix that eradicates our issues completely!

Update:

Found this issue yesterday #10976

Turns out that we had a case of a concurrent nested transaction stalling a parent transaction, which resulted in a connection to hang on the parent transaction. When this case was reached n (where n = our max pool size) times that filled our pool with hanging connections, we’d get bursts of time that ended up degrading our service. We have health checker that will kill degraded instances, so this didn’t give us complete downtime; instantiating new instances put off the problem until we reached that all-connections-in-pool-hanging state again.

We solved this by refactoring to split out the concurrent nested transaction from the parent (they weren’t actually dependent on each other). Our initial code would have the nested transaction fail silently, leaving the parent waiting for it to finish. Also did a pass through the codebase to ensure that anywhere we were doing nested transaction calls, we were passing transactions properly.

We were able to replicate the issue in staging doing something similar to the code in the issue above, so I’m fairly confident this was our issue; after shipping our fix below we aren’t seeing the same results.

Disclaimer: may or may not understand the full intricacies of connections/transactions/pooling, so take with a grain of salt!

There’s always been some issues with having N concurrent transactions where N is greater than your pool.max, i forgot the specific case but you could end up with code waiting for a connection to do something to finish up the transactions but the transactions had all the connection etc.

For reference my company has been running Sequelize against RDS for 4+ years with no issues, if there were ever connection issues it’s cause there were actually connection issues.

as @btroo and @mickhansen said, This issue happened when the count of concurrent transactions is greater than your pool.max. I’m trying to describe it in a simple way, Let’s see what happens:
What is the connection pool?

When your application needs to retrieve data from the database, it creates a database connection. Creating this connection involves some overhead of time and machine resources for both your application and the database. Many database libraries and ORM’s will try to reuse connections when possible so that they do not incur the overhead of establishing that DB connection over and over again. The pool is the collection of these saved, reusable connections that

what is concurrent transactions?
in a simple way, if you are trying to run some CRUD command in a nested transaction, it means you are using concurrent transactions. let’s assume our Sequlize config is like this:

  pool: {
    max: 7,
    min: 0,
    acquire: 30000,
    idle: 10000,
  },

we are trying to run this command:

      let nested = function() {
        // here we are making a new transaction:
        return db.sequelize.transaction(t1 => {
          // as you see in bellow command we won't use t1 transaction
          // which means our DB (in my case postgress) run below command in other transaction
          // and this is where the problem lies!
          // when we'll execute nested function, we'll create a concurrent transaction per each call
          return db.user.findOne();
        });
      };
      const arr = [];
      for (let i = 0; i < 7; i++) {
        arr.push(nested());
      }
      Promise.all(arr)
        .then(() => {
          console.log('done');
        })
        .catch(err => {
          console.log(err);
        });

The workaround is just run db.user.findOne() in t1 transaction to avoid concurrent transactions and it will be fixed:
db.user.findOne({transaction: t1})
you can also use continuation-local-storage to pass transaction automatically, just check below link:
https://sequelize.org/master/manual/transactions.html#concurrent-partial-transactions

In pool settings just keep the minimum count to about 2 to 4.
This solved the issue for me.

  pool: {
    max: 7,
    min: 2,
    acquire: 30000,
    idle: 10000,
  },

We’ve bumped into the same error. It’s weird, but we don’t have any transactions in that piece of code. It looks like a bunch of asynchronous queries to the DB, two of them use sequelize.query() to query data and the rest 8 are made with models. I don’t know why exactly, but calling one of the .query() after the others resolved somehow fixed the issue. So, we first run all those 9 queries simultaneously, and after they resolved we run the latest one. Only this worked for us.

Thanks, Your solution solved my issue.

I don’t understand how solving acquire timeout errors is fixed by reducing the timeout from the default of 60 seconds to 20?

#7884 (comment)

edit: because the default is actually 10 sec… not sure where I saw a default of 60

I don’t understand how solving acquire timeout errors is fixed by reducing the timeout from the default of 60 seconds to 20?

#7884 (comment)

edit: because the default is actually 10 sec… not sure where I saw a default of 60

I guess the key here is that 2 connections are never released («min: 2»)…

Looks like the acquire timeout is 60 seconds in sequelize v5 and v6.

I was also getting the «Unhandled rejection SequelizeConnectionAcquireTimeoutError: Operation timeout error.» I tried everything and the only one solution I got remove setınterval commands:

setInterval(
( ) => sequelize.query(«REFRESH MATERIALIZED VIEW tables»),
2601e3,

I remove this commands and problem is solved. I hope your solution will be solved very soon.