--- In firebird-support@yahoogroups.com, Norman Dunbar <Norman@...> wrote:
>
> Morning all,
>
> > I have encountered a weird network problem and have no idea what might be the cause of it.
> As far as I'm concerned, all network problems are weird! ;-)
I agreed (:

>
> > ...
> > Client connection path to the database is using TCP/IP
> > Situation: Client's program frequently shows
> > Error writing data to the connection
> > An existing connection was forcibly closed by the remote host
> That sounds to me as if the server end is killing the connection as
> opposed to the connection being "lost" due to nnetwork problems or the
> client end failing for some reason.
>

Any way for me to check if the server is actually killing the connection other than the Firebird's log file ?

> > Client stated it happened after using the program for some time.
> > As testing, I tried saving couple of big transaction on the client computer and will encountered the same error. Note: Processing time for the transaction takes less then 3 mins.
> Is the transaction doing something CPU intensive, for example a huge
> sort? If so, it's possible that there is no keep-alive on the network
> and some configuration option on the server is killing off "dead"
> connections.
>
> This is something I get occasionally with my Oracle database servers at
> work. They are configured (and I know not how!) to drop dead connections
> after a certain time. When the clients submits a huge CPU intensive
> transaction, it runs and then because there's no network traffic, the
> server assumes the connection has died and drops it.
>
> When the application tries to talk again to the server, it gets the
> message that you are seeing - force closed by remote host.
>
> > ...
>
> > Testing on network so far shows it is stable.
> Probbaly because there is plenty of traffic during the test. You need to
> have a connection initiate with the server and then, do nothing.
> Possibly an SSH to the server could be made and then simply left alone
> to see if it too dies? Of course, you need to try to get a response from
> the server in order to know if it has died or not which means that you
> have effectively reset the aliveness of the connection.
>
>

I did a testing at my office on the program. There actually a lot of traffic when the program is running. It have two steps when saving a transactions. First, it will perform checking for the transaction and it has a lot of incoming and outgoing transfer.

After that, a lot of traffic on the outgoing and then data is committed to the server.

CPU processing does not take more than 30% on a dual core machine.


> > Perform test by pinging the server and then transferring file to the server while the program is running. Will get the same error above but ping and file transfer continue without hiccup.
> I think, but I'm not a network guru, that ping uses UDP which is not TCP.
>

Yes, you are right, did not realise that. I also still the test using UDP connection as well. Same problem performance much worse.


> > Perform another test by having two program open. Only the program running the test above will crashed with error and the second program can continue being used without any problem.
> Do both programs run the same large transaction? What happens if both
> do? I predict both will lose the connection. Also, when the client is
> running the large transaction, what does Task Manager show for the
> client app - I suspect Not Responding, but I might be wrong.

Not Responding did appeared for couple of seconds at client side. It does appeared much more frequent when I test at my office though. And yes, two program will disconnect when running the same large transactions but not at the same time.


>
> And also, while the transaction is running, check the network traffic
> (start->settings->Network and Dialup connections, double click on LAN
> and see what's happening) - are you seeing sent/received clocking up
> packet counts while the transaction is running - at the same rate as
> before the transaction? Obviously there will be background traffic -
> your email, other stuff, but you might get a clue. Maybe!
>
> > ...
>
> > Also suspected something is not right with the program but running the same test at my own office with lower end computer and much heavier transaction will not have any problem. I pretty much given up and not sure what so unique about this client network that keep getting this error.
> As I said, I'm not a network guru, but it does sound familiar. I suspect
> that the server has been configured, somehow, to kill off dead
> connections and your long running transaction is thought to be dead.
>
> When you did your test on the low spec machine, were you running exactly
> the same transaction or a different one? Anything that talks across the
> network while running is going to stay alive, anything that hits the
> server for a long period of CPU, for example, is possibly going to be
> dropped.
>
> I reapet, I'm not a network guru and I'm sure others will jump in and
> assist you here, but the above may be worth considering.
>

Same type of transaction and much more heavier than client's side.



>
> And finally, the following sage advice comes from the firebird.conf file:
>
> # Normally, Firebird uses SO_KEEPALIVE socket option to keep track of
> # active connections. If you do not like default 2-hour keepalive
> # timeout then adjust your server OS settings appropriately. On
> # UNIX-like OS's, modify contents of /proc/sys/net/ipv4
> # /tcp_keepalive_*. On Windows, follow instrutions of this article:
> # http://support.microsoft.com/default.aspx?kbid=140325
>
> As Ann would say, good luck!
>

Saw that in the conf, was not sure whether to amend it.
Guess I will give it a try.

Thanks