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
Comments
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 :( |
Commented by: Thomas Kragh (realic) I believe that this issue has nothing to do with DNET585. |
Commented by: @cincuranet Do you have steps to reproduce? |
Commented by: Thomas Kragh (realic) Yes I have. 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. |
Commented by: @cincuranet Yeah. The test program wood be great. |
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 |
Modified by: Thomas Kragh (realic)Attachment: FbConnectionPoolBugTest.zip [ 12684 ] |
Modified by: @cincuranetstatus: Open [ 1 ] => In Progress [ 3 ] |
Modified by: @cincuranetstatus: In Progress [ 3 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: vNext [ 10704 ] |
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
The text was updated successfully, but these errors were encountered: