Issue Details (XML | Word | Printable)

Key: DNET-917
Type: Bug Bug
Status: Resolved Resolved
Resolution: Won't Fix
Priority: Minor Minor
Assignee: Jiri Cincura
Reporter: Patrick Frießnegg
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
.NET Data provider

Connection Pool - FbConnectionInternal.Database.BrokenConnection

Created: 08/Nov/19 10:51 AM   Updated: 20/Feb/20 09:03 AM
Component/s: ADO.NET Provider
Affects Version/s: 7.1.1.0
Fix Version/s: None


 Description  « Hide
When a network issue leads to a broken connection (like you kill fbinet.exe in classic mode) you get following exception:

Message "Unable to complete network request to host \"\r\nNo message for error code 335544721 found." string
   at FirebirdSql.Data.FirebirdClient.FbCommand.ExecuteScalar()
in C:\Synesc.GmbH\source\git\FirebirdSql.Data.FirebirdClient\Provider\src\FirebirdSql.Data.FirebirdClient\FirebirdClient\FbCommand.cs:line 528
+ ex.GetType() {Name = "FbException" FullName = "FirebirdSql.Data.FirebirdClient.FbException"} System.Type {System.RuntimeType}


This does set FbConnectionInternal.Database.BrokenConnection to true, so the connection is not put back into the connectionpool.
But if you simulate the same issue with "delete from mon$attachments" you get:

Message "connection shutdown" string
   at FirebirdSql.Data.FirebirdClient.FbCommand.ExecuteScalar()
in C:\Synesc.GmbH\source\git\FirebirdSql.Data.FirebirdClient\Provider\src\FirebirdSql.Data.FirebirdClient\FirebirdClient\FbCommand.cs:line 528
+ ex.GetType() {Name = "FbException" FullName = "FirebirdSql.Data.FirebirdClient.FbException"} System.Type {System.RuntimeType}


In this case, FbConnectionInternal.Database.BrokenConnection is not set and therefore the connection IS put back into the connectionpool.
But this connection is still permanently broken. The next time it's used, it's 100% going to fail.

It is a minor issue tho, because in the second attempt it will throw the exception #1, and therefore clean itself after.
But still the software will always require a second attempt to request the database.


related to
http://tracker.firebirdsql.org/browse/DNET-668
http://tracker.firebirdsql.org/browse/DNET-818
http://tracker.firebirdsql.org/browse/DNET-916

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Jiri Cincura added a comment - 12/Nov/19 10:10 AM - edited
Hmm, the problem is, that after the `delete from mon$attachments` server properly sends back the response, containing the exception that's thrown, and *then* server closes the connection. So at the moment of processing the response from server, the fact that the connection will be closed is not known.

Maybe handling the 335544721 explicitly would make sense. But it's not specific and I'm not sure where else it might originate. I have to think about that more.

Patrick Frießnegg added a comment - 14/Nov/19 09:46 PM
Issue my not be as minor as previously thought.

My temporary Unittest-Fix for this issue in PR90 does work locally on my machine, but on CI pipeline of the project the second SQL does NOT trigger the connection to be broken.
Which would mean that we end up with a pool of broken connections all over again.

But i can't tell whats the difference between the CI and local setup tho.
So at least users working with mon$attachment deletes can possibly have issues. Not aware of other dc-variations

Jiri Cincura added a comment - 20/Feb/20 09:02 AM
The 335544721 that's a result of the deletion isn't unique to this and can happen in other places. That means at the moment this has no easy way out. And given the problem corrects itself on next turn (and "next-turn-error" handling should be in application anyway), I'll leave it as is at the moment and maybe in the future it can be reevaluated.