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

FbConnectionPoolManager not closing connections [DNET595] #560

Closed
firebird-automations opened this issue Mar 6, 2015 · 9 comments
Closed

Comments

@firebird-automations
Copy link

Submitted by: Thomas Kragh (realic)

Attachments:
FbConnectionPoolBugTest.zip

Votes: 1

I believe to have found at problem in FbConnectionPoolManager. In my case the problem shows on a website where there is a spike in user activity in the morning, the user activity results in about 75-100 attachments to the database. However after the spike, the connections/attachments to the database remains. The Connection lifetime is set to 15 in my connectionstring.

After digging around in the sourcecode I believe I have found the problem in FbConnectionPoolManager, where a Queue<Item> is used to hold available connections. The FIFO nature of the Queue results in every available connections to be checked out of the pool within 15 seconds if there is enough database activity. Thus keeping the 75-100 connection/attachment to the database open for a long period (usually 6-8 hours)

I believe using a Stack<Item> instead of Queue<Item> could solve the problem.

Commits: fbbb649 72f6523

@firebird-automations
Copy link
Author

Commented by: @luronumen

Since the http://ADO.NET Provider v.4.6.0.0 the FirebirdSQL Connection Pooling (http://ADO.NET) is not Working but the Jiri Cincura insist that this is not a issue :(
See DNET585

@firebird-automations
Copy link
Author

Commented by: Thomas Kragh (realic)

I believe that this issue has nothing to do with DNET585.

@firebird-automations
Copy link
Author

Commented by: @cincuranet

Do you have steps to reproduce?

@firebird-automations
Copy link
Author

Commented by: Thomas Kragh (realic)

Yes I have.
I will try to describe it in some steps, if you need me to write a test program just say so.

1 Have a program start 50 threads, that each execute "select current_timestamp from mon$database" 200 times. The goal here is to create alot of connections to the database. Make sure that the connection is fetched and returned to the connectionpool every time you execute this statement.

2 Wait for the 20 threads to finish.

3 Have a single thread execute "select current_timestamp from mon$database" for about a minute. Make sure that the connection is fetched and returned to the connectionpool every time you execute this statement. If the Connection lifetime is set to 15 seconds, this should give the ConnectionPoolManager enough time to close connections that has not been "checked out" of the connectionpool for that period of time. However connections in the connectionpool are not closed, because the single thread cycles through every connection in the connectionpool, because of a FIFO queue is used.

I hope this describes the problem better. The core problem is that a single thread making alot of requests to the database can keep alot of connections/attachments to the server alive.

@firebird-automations
Copy link
Author

Commented by: @cincuranet

Yeah. The test program wood be great.

@firebird-automations
Copy link
Author

Commented by: Thomas Kragh (realic)

Here is at test project that demoostrates the problem. Please have a look at the connectionstring at supply your own information to a database

@firebird-automations
Copy link
Author

Modified by: Thomas Kragh (realic)

Attachment: FbConnectionPoolBugTest.zip [ 12684 ]

@firebird-automations
Copy link
Author

Modified by: @cincuranet

status: Open [ 1 ] => In Progress [ 3 ]

@firebird-automations
Copy link
Author

Modified by: @cincuranet

status: In Progress [ 3 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: vNext [ 10704 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants