Using 3.30 B1, CS.

Is it common to have multiple entries, such as

2/26/2015 9:11:44 AM Internal error removing dead session - Access violation at address 004A6E99 in module 'dbsrvr.exe'. Read of address 2615A63C[User: kc Last Address: 192.168.5.42 Session: 45684680]

In a 24 hour period, with approx 60-70 users, I may see 20+ entries such as this.  In looking at the server code, it appears that during dead session cleanup, all sessions are iterated, and  if a session qualifies to be freed, it's freed.  This exception is raised when the call to free fails.

Also,does DBRSVR reuse sessions?  I noticed in one of my logs that a user logs out from 192.168.5.146 with session id 613811196, then 5 minutes later 192.168.5.152 gets the same session id 613811196, albeit with different thread ids.

My server settings are:
Max connections: 38,527
Connection timeout: 360
Dead session cleanup: 120
Dead session expiration: 300
Max # of dead sessions: 0

I have a keep alive in my app at 60 seconds.

Any help would be appreciated.

On 2/27/2015 6:58 PM, John Easley wrote:
> Using 3.30 B1, CS.
> Is it common to have multiple entries, such as
> 2/26/2015 9:11:44 AM Internal error removing dead session - Access violation at address 004A6E99 in module 'dbsrvr.exe'. Read of address 2615A63C[User: kc Last Address: 192.168.5.42 Session: 45684680]

Have not used v3 in years but i do recall seeing some of those in
earlier v4 versions as well.

The main question of course is why do you end up with dead session to
begin with - in normal operation app should close its sessions and these
should not happen at all. Is the client app losing connection somehow
(PC going asleep with app running or users on unreliable wireless or
such) ?

> In a 24 hour period, with approx 60-70 users, I may see 20+ entries such as this.  In looking at the server code, it appears that during dead session cleanup, all sessions are iterated, and  if a session qualifies to be freed, it's freed.  This exception is raised when the call to free fails.

That sounds a lot to me for 24 hours - i'd tackle the why the app does
not close its sessions properly question from above.

> Also,does DBRSVR reuse sessions?  I noticed in one of my logs that a user logs out from 192.168.5.146 with session id 613811196, then 5 minutes later 192.168.5.152 gets the same session id 613811196, albeit with different thread ids.

Not sure on this one.

> My server settings are:
> Max connections: 38,527
> Connection timeout: 360
> Dead session cleanup: 120
> Dead session expiration: 300
> Max # of dead sessions: 0

These are fairly aggressive but look ok to me.

> I have a keep alive in my app at 60 seconds.

How is this implemented (timer? - any chance it gets blocked and does
not run as frequently as needed)?

One thing to test would be to increase the connection timeout and see
what effect this has.

Raul

Thank you Raul for your reply.

Users are on a local LAN, very reliable gig ethernet.

It's impossible to control how 60-70 users will terminate an application.  Of course they should log out, but terminating in other ways is uncontrollable. Maybe they click on a lengthy report, and decide they don't want to wait, and end the app... there are a myriad of reasons for terminating an application the wrong way, most probably have to do with lack of patience.  You can't teach patience,  unfortunately

Dead sessions are a part of DBISAM's DNA, my question is, why is the server having a difficult time freeing them, and what affect does that have on the server?

>>How is this implemented (timer? - any chance it gets blocked and does
not run as frequently as needed)?

Yes, it's implemented in a timer.  The only thing that would block the timer would be database access to the server, so I don't think the timer is the problem. I originally had the connection timeout at 70 seconds, and recently increased to 360, and not much change.

I'm not sure I want to invest the time to upgrade our application to version 4.x, because in reading the newsgroups, these issues are apparent in both 3.x and 4.x.

John

On 2/28/2015 2:15 PM, John Easley wrote:
> Dead sessions are a part of DBISAM's DNA, my question is, why is the server having a difficult time freeing them, and what affect does that have on the server?

John,

Tim would be only one that can tell you exactly what, if any, impact the
AV has - or if you want to debug the server code to see where it is
exactly thrown you'd be able to determine as well.

Since you're not seeing any lock issues I'd say the impact is none to
maybe some small memory leaks (depending where AV is thrown and whether
all memory de-allocations take place after). You can monitor dbsrvr
memory usage to see if it creeps up over time.

I know we never had any issues related to this AFAIK.

> I'm not sure I want to invest the time to upgrade our application to version 4.x, because in reading the newsgroups, these issues are apparent in both 3.x and 4.x.

In later v4 versions Tim re-wrote lot of this logic so in current v4
this should never happen. In fact this was one of the main release notes
for 4.35 ("DBISAM 4.35 finally fixes an ongoing issue with dead session
removal in the DBISAM Database Server") and also 4.38 and later fixed
some additional session issues introduced as part of 64bit i believe.

Migration would be bit of work depending on how you use v3 (SQL vs
delphi components etc).  If you're not seeing any ill effects in the app
and dbsrvr works ok then i'd say it's something you can ignore (or just
automatically restart dbsrvr service on regular basis just in case so
any memory or other resource issues would be cleared).

Raul

John


A question that Raul hasn't asked - is this a single or multi threaded program? If multi threaded that could explain what you're seeing. I think.

Roy Lambert

Roy,

It's a single-threaded app.

John