| Subject | 2.1.3 CS - server hang |
|---|---|
| Author | s3057043 |
| Post date | 2010-11-01T01:02:04Z |
Hello Group,
I have a customer who is encountering an unusual problem with Firebird 2.1.3 Classic Server on Windows 2008 R2.
At some time this morning, our application froze on the server. Further investigation into this showed that it was the connection to the Firebird database that was causing the problem. We attempted to use several different applications (both internal and third party) to connect to the database with but without success. Even iSQL could not connect. iSQL froze for a number of minutes and the task had to be killed and the server restarted.
There were a number of "INET/inet_error: read errno = 10054" and "SERVER/process_packet: broken port, server exiting" errors in Firebird.log around the time of the failure. These errors occur at other times as well, but are far more frequent after the failure before the restart. This may or may not be related.
We took a tasklist on the server prior to restart, and there were about 800 fb_inet_server.exe processes. The tasklist indicated the memory usage for about 525 of these processes was below 4MB (300 were below 2MB). I didn't think to check whether the number of fb_inet_server.exe processes increased with every frozen connection but based on the load for that server, I only expected there to be around 250 attachments at this time. I am therefore suspicious that each of the connection attempts (eg iSQL above) was indeed spawning an fb_inet_server.exe instance but that something went wrong along the way.
We confirmed (using telnet to port 3050) from one of the application servers that even when the database server was not completing the connection requests, the network connectivity to the Firebird port was working.
My questions are:
Does anyone know what conditions might cause that a database connection may lock up during the connection in a way that would create an fb_inet_server.exe processes?
Are these errors in Firebird.log particularly concerning or just part of the "real world" networking environments?
Is there something else I should be looking into?
Thanks in advance
Adam
I have a customer who is encountering an unusual problem with Firebird 2.1.3 Classic Server on Windows 2008 R2.
At some time this morning, our application froze on the server. Further investigation into this showed that it was the connection to the Firebird database that was causing the problem. We attempted to use several different applications (both internal and third party) to connect to the database with but without success. Even iSQL could not connect. iSQL froze for a number of minutes and the task had to be killed and the server restarted.
There were a number of "INET/inet_error: read errno = 10054" and "SERVER/process_packet: broken port, server exiting" errors in Firebird.log around the time of the failure. These errors occur at other times as well, but are far more frequent after the failure before the restart. This may or may not be related.
We took a tasklist on the server prior to restart, and there were about 800 fb_inet_server.exe processes. The tasklist indicated the memory usage for about 525 of these processes was below 4MB (300 were below 2MB). I didn't think to check whether the number of fb_inet_server.exe processes increased with every frozen connection but based on the load for that server, I only expected there to be around 250 attachments at this time. I am therefore suspicious that each of the connection attempts (eg iSQL above) was indeed spawning an fb_inet_server.exe instance but that something went wrong along the way.
We confirmed (using telnet to port 3050) from one of the application servers that even when the database server was not completing the connection requests, the network connectivity to the Firebird port was working.
My questions are:
Does anyone know what conditions might cause that a database connection may lock up during the connection in a way that would create an fb_inet_server.exe processes?
Are these errors in Firebird.log particularly concerning or just part of the "real world" networking environments?
Is there something else I should be looking into?
Thanks in advance
Adam