[#DNET-595] FbConnectionPoolManager not closing connections

.NET Data provider

FbConnectionPoolManager not closing connections

Created: 06/Mar/15 02:43 PM Updated: 23/Jul/15 12:12 PM

Component/s:

ADO.NET Provider

Affects Version/s:

None

Fix Version/s:

4.7.0.0

File Attachments:	1. FbConnectionPoolBugTest.zip (1.86 MB)
Environment:	any

Description

« Hide

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.

All

Comments

Change History

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Luciano Mendes added a comment - 07/Mar/15 01:30 AM

Since the ADO.NET Provider v.4.6.0.0 the FirebirdSQL Connection Pooling (ADO.NET) is not Working but the Jiri Cincura insist that this is not a issue :(
See http://tracker.firebirdsql.org/browse/DNET-585

[ Permalink | « Hide ]

Thomas Kragh added a comment - 07/Mar/15 08:15 AM

I believe that this issue has nothing to do with ~~DNET-585~~.

[ Permalink | « Hide ]

Jiri Cincura added a comment - 07/Mar/15 11:47 AM

Do you have steps to reproduce?

[ Permalink | « Hide ]

Thomas Kragh added a comment - 07/Mar/15 12:59 PM

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.

[ Permalink | « Hide ]

Jiri Cincura added a comment - 07/Mar/15 01:24 PM

Yeah. The test program wood be great.

[ Permalink | « Hide ]

Thomas Kragh added a comment - 17/Mar/15 05:30 PM

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