Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
Internal error removing dead session |
Fri, Feb 27 2015 6:58 PM | Permanent Link |
John Easley | 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. |
Sat, Feb 28 2015 10:58 AM | Permanent Link |
Raul Team Elevate | 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 |
Sat, Feb 28 2015 2:15 PM | Permanent Link |
John Easley | 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 |
Sat, Feb 28 2015 3:14 PM | Permanent Link |
Raul Team Elevate | 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 |
Sun, Mar 1 2015 3:02 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sun, Mar 1 2015 10:32 AM | Permanent Link |
John Easley | Roy,
It's a single-threaded app. John |
This web page was last updated on Wednesday, April 17, 2024 at 10:35 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |