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

DummyPacketInterval mechanism broken [CORE1357] #1775

Closed
firebird-automations opened this issue Jul 16, 2007 · 10 comments
Closed

DummyPacketInterval mechanism broken [CORE1357] #1775

firebird-automations opened this issue Jul 16, 2007 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: michalk1 (michalk1)

Relate to CORE2137

After DummyPacketInterval period elapses, connection is forcibly closed. It seems that dummy packets are not generated properly or don't get through, which makes the connection treated as lost and consecutively closed by the server side.

Steps to reproduce the problem:

1) Set DummyPacketInterval in firebird.conf to 60 seconds and restart the server.

2) Run FlameRobin (or another application) and connect to any database through TCP/IP.

3) Wait for about 3 minutes without any database activity.

4) Run some SQL statement. The result is following error message about lost connection and record written into FB's log file:

Unable to complete network request to host
Error reading data from the connection.

INET/inet_error: read errno = 10053

Btw., although (according to comment in firebird.conf) the preferred way to detect orphaned client connections is now a change of TCP system constants, DummyPacketInterval still has an important advantage in that it is local setting. TCP constants on the other hand are global, system-wide settings that affect all applications running on the server machine and their change from default 2 hours down to several minutes may broke some of them. At least it's risky to change them on customer's machine over which you don't have direct control. The memory leak described in firebird.conf impacts especially "connection pool" type of applications that keep large amount of possibly inactive connections open for a long time. For applications that open just several connections and are not supposed to be left running inactive for days the DummyPacketInterval still may be a better choice.

Commits: c74650a 5cc6302 b5950f6

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 12590 ] => Firebird [ 14172 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ] => Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Open [ 1 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

Fix Version: 2.1.1 [ 10223 ]

Fix Version: 2.0.5 [ 10222 ]

Planning Status: Considered for inclusion

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Open [ 1 ]

Planning Status: Considered for inclusion => Included to release

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE2137 [ CORE2137 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

environment: Windows XP => Any

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment