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
Firebird 2.1.3 64bit superserver - hanging TCP conenctions [CORE3002] #3384
Comments
Commented by: @dyemanov SuperServer or Classic? |
Commented by: Karel Rys (vandrovnik) Superserver - sorry, I put this info in subject only. |
Commented by: @dyemanov How long are those connections left open? DummyPacketInterval = 120 means two minutes between pings. Also, have you tried to reduce the default TCP keep-alive interval on Windows? Did it help? |
Commented by: Karel Rys (vandrovnik) On windows, these connections are not active in the system. Netstat -a -n does not show them at all. Firebird was restarted 50 hours ago. It seems that Firebird does not try to ping these conenctions, or it does try, but does not remove them, even thought connections are already dead. |
Commented by: @dyemanov Does the connection count returned via the server properties (server tray icon or Services / Server Properties in IBExpert) match the one returned with select count(*) from mon$attachments? |
Commented by: Karel Rys (vandrovnik) Yes, at this moment, both show 5. Server Version Info Configuration Info Database Info |
Commented by: Karel Rys (vandrovnik) netstat -a -n TCP 192.168.1.2:3050 192.168.1.2:33824 NAVAZANO (NAVAZANO = connected or something like that) There are no other connection to TCP 192.168.1.2:3050 |
Commented by: @dyemanov Does MON$ATTACHMENTS list all of them with value "TCPv4" in the MON$REMOTE_PROTOCOL field? |
Commented by: Karel Rys (vandrovnik) Yes, it does (there are more connections to the server at this moment, than before, when I wrote, that there where 5 connections): MON$ATTACHMENT_ID MON$SERVER_PID MON$STATE MON$ATTACHMENT_NAME MON$USER MON$ROLE MON$REMOTE_PROTOCOL MON$REMOTE_ADDRESS MON$REMOTE_PID MON$CHARACTER_SET_ID MON$TIMESTAMP MON$GARBAGE_COLLECTION MON$REMOTE_PROCESS MON$STAT_ID |
Commented by: Karel Rys (vandrovnik) About Firebirds ability to detect dead connections: I think Firebird sends a ping packet and waits for the answer. May be when there is already error during sending this ping packet, this situation is not handled correctly and server never destroys such a connection? |
Commented by: @hvlad > Firebird sends a ping packet and waits for the answer. No, it not waits for the answer on dummy packet > May be when there is already error during sending this ping packet, this situation is not handled correctly and server never destroys such a connection? All socket errors, returned by the OS : > Most of the problems happen at 192.168.1.3, customer told me now, that this IP address belongs to a terminal server connection. Do you have any network software on your server, such as firewall, antivirus, etc ? > Anyhow, when the TCP connection does not exist at operating system level, it should be destroyed by Firebird too. Of course. But if OS didn't notified Firebird about broken connection - how it could know about it ? BTW, how client application owned of "hung" connections was closed - correctly or not ? |
Commented by: Karel Rys (vandrovnik) Customer has ESET Mail Security 4 For Microsoft Exchange Server installed on the server, and they probably have windows firewall enabled. Unfortunatelly, I do not know, how they close the application - I can imagine that sometimes their connection is just broken because of network problems... FbClient.dll renamed to gds32.dll: I think Firebird should recognize a problem, when it tries to send ping packet over a non-existing connection (non-existing at the operating system level). Is it possible to enable debugging messages? I would like to see, what is going on with these connections - logging of each ping packet and a response would help a lot... In firebird.log, there are messages like this: SERVER (Server) Mon May 10 10:31:05 2010 SERVER (Server) Mon May 10 10:48:17 2010 |
Modified by: Karel Rys (vandrovnik)security: Developers [ 10012 ] => |
Commented by: Evelyne Girard (evelyne) I had the same kind of problem with Firebird 2.1 (17910) 32-bits SuperServer. The server considered some old connections as active even after the client application was closed. It kept those attachments actives forever (several weeks). It didn't matter if I restarted the client computer, the server still considered the attachment active. I have upgraded the server to 2.5 (changed nothing else except the fbclient.dll used by clients of course) and the problem is now fixed. |
Submitted by: Karel Rys (vandrovnik)
At the server side, there are left unclosed attachments.
These conenctions are closed at OS level (netstat -a -n does not list them).
Firebird still lists them in MON$ATTACHMENTS.
In Firebird.conf, I have set up:
ConnectionTimeout = 300
DummyPacketInterval = 120
Unfortunatelly, this does not help and connections are open, until Firebird is restarted.
The text was updated successfully, but these errors were encountered: