Issue Details (XML | Word | Printable)

Key: CORE-1357
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Dmitry Yemanov
Reporter: michalk1
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

DummyPacketInterval mechanism broken

Created: 16/Jul/07 05:35 AM   Updated: 19/Jan/16 05:07 AM
Component/s: Engine
Affects Version/s: 2.0.0, 2.0.1, 2.1 Beta 1
Fix Version/s: 2.5 Alpha 1, 2.1.1, 2.0.5

Environment: Any
Issue Links:

Planning Status: Included to release
QA Status: No test

 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.