Firebird server leaking handles using .net provider > 5.12.0.0
--------------------------------------------------------------

                 Key: DNET-852
                 URL: http://tracker.firebirdsql.org/browse/DNET-852
             Project: .NET Data provider
          Issue Type: Bug
          Components: ADO.NET Provider, Entity Framework
    Affects Versions: 6.3.0.0, 6.2.0.0, 6.1.0.0, 6.0.0.0, 5.12.1.0
         Environment: Windows 7, Windows Server 2016
            Reporter: Dominik Psenner
            Assignee: Jiri Cincura
            Priority: Blocker


After an update of the firebird ado.net driver from 5.12.0 to 5.12.1 or 6.3 we 
observe that the firebird server 2.5.x leaks memory that is related to a 
connection and/or the statements that a client runs against the firebird 
database using the ado.net provider > 5.12.0.

We observe both an increase in the private memory set (4GB) but also the 
nonpaged pool increases significantly (5000K) in the firebird server process 
until the firebird server process is no longer able to handle any statements. 
At this point the server returns IscError 335544761 "too many open handles to 
database" and the SQLSTATE is "HY000". This causes the offending client to 
crash.

As soon as the connection closes, the firebird server is able to recover. It 
does then free the allocated memory and the nonpaged pool decreases back to 
normal (<160K).

This may relates to changes implemented with in release 5.12.1. Before ado.net 
provider 5.12.1, the connection pool to the firebird server did not work 
properly and connections were closed too early. Connections used to be always 
short-living. 5.12.1 fixed that and from then on connections are properly 
pooled. This causes connections to become long-living as long as there is 
activity. If connections are not closed, the server end will not end up the 
resources it has allocated and sooner or later show the symptom observed.

We cannot disable the connection pool because of performance reasons. We cannot 
revert back to 5.12.0 because the connection pool would not work either and we 
have no further option. Therefore I set the priority of this issue to blocker.

We do also have a minimal sample application that reproduces the issue with a 
very simplistic database containing only one table with three columns.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


_______________________________________________
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Reply via email to