Hi,

I'm using a client connected to a remote DBISAM server, both version 4.40. I'm having the following problem:

-the client executes a 'UPGRADE TABLE IF EXISTS x; UPGRADE TABLE IF EXISTS y; UPGRADE TABLE IF EXISTS z'
-the server starts upgrading the tables. one of the tables is a big table and its upgrade takes 20 minutes, most spent on recreating the .ifx file
-after a while (5 to 10 minutes) the client causes an error: DBISAM Engine Error # 11276 The connection to the database server at '127.0.0.1' has been lost.
-the server is now still happily upgrading the big table (as shown by cpu usage and increasing .idx size)
-also, the server still shows (via srvadmin) the client as connected even though it's not. even if you exit the client it still shows as connected
-as soon as the server is done upgrading it will also show the client as disconnected

My question: is this behaviour (especially the disconnect error) as desinged? I didn't expect it since the upgrade is functioning normally and would want the client to simply wait till the upgrade completed. Is it the client or the server that initiates the disconnect? What's the recommended workaround? Also, does the same issue occur if a query takes a long time to process?

The server is a stock 64 bit dbsrvr.exe. It's connection timeout is set to 300 seconds.

Thanks & greetings,
Martijn Laan

'.ifx' above should have been '.idx'

Martin

You should read ping feature at session level. It will create a special connection with the server that prevents this kind of situation.

Thanks, I've read about the RemotePing property before but to me it does not seem to be designed for this case? According to the documentation it "allows for the use of a smaller dead session expiration time and can be used to prevent dangling locks when a client workstation shuts down and leaves an open session on the database server." But in the above case everything is working normally and pinging seems overkill / should not be needed?

Martijn


From what you've posted it sounds normal to me. You've set a timeout of 300 seconds and then the server goes off and does its own thing for around 1200 seconds so no input from the client which makes it think the client is dead.

I think (I'm using ElevateDB these days) DBISAM has a session.RemotePing property which will keep the connection alive. You'll need to set that at a value below the timeout of 300 seconds.


Roy Lambert

Thanks Roy. I don't think it sounds normal at all. How can it ever be ok for the server to think a client is dead when its actually still performing work for said client. That makes no sense? And why would it then still display such a 'dead' client as connected in srvadmin?

But I will try RemotePing. Unlike what Jose said I don't think it uses a second connection after a quick look at the code so it's not as overkill ish as I thought. I do wonder if it has other drawbacks I'm not aware about since its not enabled by default but without enabling it things don't really work. So there must be some special reason it's not enabled by default? Note the 300 seconds timeout on the server is the default and not something I set myself.

On 12/8/2014 5:06 AM, Martijn Laan wrote:
> My question: is this behaviour (especially the disconnect error) as desinged? I didn't expect it since the upgrade is functioning normally and would want the client to simply wait till the upgrade completed. Is it the client or the server that initiates the disconnect? What's the recommended workaround? Also, does the same issue occur if a query takes a long time to process?
>
> The server is a stock 64 bit dbsrvr.exe. It's connection timeout is set to 300 seconds.

This is normal with the timeout you have - dbisam has no way of knowing
how long the operations take so once the timeout expires the client
dbisam is the one that causes the disconnect.

Server side thread is still busy with the upgrade processing .

Couple of things you can do in addition to remoteping as other have
suggested:
- handle the OnRemoteTimeout even on client side if you know it's a long
operation and set the StayConnected to true
- increase the RemoteTimeout itself

Raul

Thanks Raul, somehow I missed (On)RemoteTimeout. Seems to be exactly what I was looking for.

Martijn

>Thanks Roy. I don't think it sounds normal at all. How can it ever be ok for the server to think a client is dead when its actually still performing work for said client. That makes no sense? And why would it then still display such a 'dead' client as connected in srvadmin?

I can understand your point of view. The server considers the connection is live and working when information is moving back and forth over it, not when the cpu is hammering away. Think if you physically pulled the cable (or if its a wireless connection hit the PC with a big hammer or put it in a faraday cage) or turned the power off. The server would still be running away but there's definitely no connection in that case

There are a number of settings that determine how the server deals with sessions. Sorry I can't remember the proper names but roughly there's the timeout - how long the server waits before it decides that the connection is dead; dead session cleanup - how long the server waits before it removes the sessions it thinks are dead - this gives things a chance to reconnect and carry on as before. I don't know if the DBISAM server has the same interface as the ElevateDB one, but if these aren't listed for editing then have a look in the ini file associated with the server.

>But I will try RemotePing. Unlike what Jose said I don't think it uses a second connection after a quick look at the code so it's not as overkill ish as I thought. I do wonder if it has other drawbacks I'm not aware about since its not enabled by default but without enabling it things don't really work. So there must be some special reason it's not enabled by default? Note the 300 seconds timeout on the server is the default and not something I set myself.

Jose didn't say it uses a second session - it wouldn't work if it did! Its not enabled by default mainly because it didn't appear for a long time in DBISAM (not sure when) and setting it true by default could have broken existing setups, or resulted in conflicts where people were already doing their own thing.

Roy Lambert

Ok, I believe I've found the 'real' solution to my problem:

First I noticed this sentence in the RemoteTimeout documentation: "The server may just simply be executing a very long process and has not sent a progress message in a longer period of time than what is configured for the RemoteTimeout property".

Then I found using the DBISAM code that for table upgrades the server sends these progress messages only if a OnUpgradeProgress event has been set on the client side.

So I added an empty OnUpgradeProgress to my TDBISAMQuery and that fixed the problem. The server is now sending progress back to my client during the lenghty table upgrade which prevents the client from disconnecting due to a timeout (in dbisamen.pas's TDataSession.Receive).

Thanks for all the responses