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

Connection Pool - FbConnectionInternal.Database.BrokenConnection [DNET917] #844

Closed
firebird-automations opened this issue Nov 8, 2019 · 6 comments

Comments

@firebird-automations
Copy link

Submitted by: Patrick Frießnegg (trynn)

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
DNET668
DNET818
DNET916

@firebird-automations
Copy link
Author

Modified by: Patrick Frießnegg (trynn)

description: 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\synesc.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\synesc.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
DNET668
DNET818
DNET916

=>

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
DNET668
DNET818
DNET916

@firebird-automations
Copy link
Author

Commented by: @cincuranet

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.

@firebird-automations
Copy link
Author

Modified by: @cincuranet

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

@firebird-automations
Copy link
Author

Commented by: Patrick Frießnegg (trynn)

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

@firebird-automations
Copy link
Author

Commented by: @cincuranet

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.

@firebird-automations
Copy link
Author

Modified by: @cincuranet

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

resolution: Won't Fix [ 2 ]

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