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
Comments
Modified by: @dyemanovassignee: Vlad Khorsun [ hvlad ] |
Modified by: @pcisarWorkflow: jira [ 12590 ] => Firebird [ 14172 ] |
Modified by: @dyemanovassignee: Vlad Khorsun [ hvlad ] => Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovstatus: 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 |
Modified by: @dyemanovstatus: Open [ 1 ] => Open [ 1 ] Planning Status: Considered for inclusion => Included to release |
Modified by: @dyemanovenvironment: Windows XP => Any |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
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
The text was updated successfully, but these errors were encountered: