You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I needed some time to spot the issue in your Pool implementation. The current implementation is not considering the async nature of "providing an new connection" and so can easiely give out more connections as allowed.
Example: Assume I have a maximum pool of 20 connections I want to allow. And now I start fresh with 0 connections directly after "Open" call: When I now do a loop to borrow 200 connections then I will get them ... so was over the top
With my "loop of 200" the first check is always ok and so I get 200 connections ... and active is 200 afterwards
I would propose to always increase the counter before the check in assumption that you get a connection and decrease afterwrdas if this was a wrong assumption
The text was updated successfully, but these errors were encountered:
Apollon77
added a commit
to Apollon77/sql-client
that referenced
this issue
May 24, 2022
Hi,
I needed some time to spot the issue in your Pool implementation. The current implementation is not considering the async nature of "providing an new connection" and so can easiely give out more connections as allowed.
Example: Assume I have a maximum pool of 20 connections I want to allow. And now I start fresh with 0 connections directly after "Open" call: When I now do a loop to borrow 200 connections then I will get them ... so was over the top
Reason is:
1 first you check if current active connections are already more then allowed done in https://github.com/intellinote/sql-client/blob/master/lib/sql-client-pool.coffee#L108-L110 is
2 if this is ok (and no free connection is in pool which can not be in my example) then you create a connection (which is asnyc!)
3 if it was ok then you increase active counter in https://github.com/intellinote/sql-client/blob/master/lib/sql-client-pool.coffee#L144
With my "loop of 200" the first check is always ok and so I get 200 connections ... and active is 200 afterwards
I would propose to always increase the counter before the check in assumption that you get a connection and decrease afterwrdas if this was a wrong assumption
The text was updated successfully, but these errors were encountered: