| Subject | Re: [firebird-support] error INET/inet_error: read errno = 10054 or 10038 or 10093 |
|---|---|
| Author | Helen Borrie |
| Post date | 2010-05-30T18:56:07Z |
At 05:18 AM 29/05/2010, flournoymike wrote:
Clients won't be able to connect to a database if there's no Firebird server running. Noting the error message they get on failing to connect is often useful.
Network error events happen all the time. "The network tested out fine" is pretty meaningless. A client connection works when both ends are communicating. If one side is terminated abnormally, you get a socket error (which these all are).
The ones the firebird.log records are those that interfere with what Firebird or its clients expect at, or soon after, the time of occurrence. 10054 and 10038 typically occur when someone reboots the server's host machine or shuts down Firebird while clients are active. 10093 can happen when clients try to connect to the server before the network has started up...note how this correlates with the other two, especially if they tend to cluster in that order.
* Look in firebird.log for any Firebird errors that are logged at the same time.
* Find out whether there is a user there who thinks rebooting the host server is a way to make slow applications go faster, and subject him/her to some in-service training! ;-)
Note that there are plenty of other reasons client/server sockets can be broken. Amongst them, a badly-behaved UDF can crash the server... so can a mega-buildup of garbage due to transactions that never commit. These are issues the developer must address.
./heLen
>I am getting this error INET/inet_error: read errno = 10054 or 10038 or 10093. This only happens a couple times a week. When it does happen clients are unable to connect to the Database. It looks like previous connections are not being released and Firebird is being overworked.Is there something you haven't mentioned that leads you to this conclusion?
Clients won't be able to connect to a database if there's no Firebird server running. Noting the error message they get on failing to connect is often useful.
>The solution to the problem is to check my network. The network tested out fine. Do you have any ideas on what I need to change to get this to stop happening?It goes without saying, of course, that it's essential to keep databases and Firebird's files out of the clutches of System Restore, disk shadowing and anti-virus programs!
Network error events happen all the time. "The network tested out fine" is pretty meaningless. A client connection works when both ends are communicating. If one side is terminated abnormally, you get a socket error (which these all are).
The ones the firebird.log records are those that interfere with what Firebird or its clients expect at, or soon after, the time of occurrence. 10054 and 10038 typically occur when someone reboots the server's host machine or shuts down Firebird while clients are active. 10093 can happen when clients try to connect to the server before the network has started up...note how this correlates with the other two, especially if they tend to cluster in that order.
* Look in firebird.log for any Firebird errors that are logged at the same time.
* Find out whether there is a user there who thinks rebooting the host server is a way to make slow applications go faster, and subject him/her to some in-service training! ;-)
Note that there are plenty of other reasons client/server sockets can be broken. Amongst them, a badly-behaved UDF can crash the server... so can a mega-buildup of garbage due to transactions that never commit. These are issues the developer must address.
./heLen