Web Sessions Not Clearing

I have a stand alone web application that runs on a Windows Server 2008R2 server and connects to a SQL Server 2012 database.

At the customer’s site, I’m having a big problem with WebSessions not clearing. I have a status page that lists the active sessions and so I can see when sessions are cleared. Once a session is “stuck” on the list, no further sessions are cleared and the application’s memory climbs until it falls over. The only thing I can do then is to reset the application.

I have the app.SessionTimeout set to 10 seconds so I’m expecting sessions to disappear from the list after this amount of time (approximately).

When I run my application in our test environment, the sessions clear off the list as expected. I have never seen a stuck session in my development or test environments.

On the customer’s site, the sessions sit on the list with an ActiveConnectionCount = 1. Sometimes, after a few minutes, this goes to zero and the session is cleared. More often than not, the ActiveConnectionCount remains at 1 and the session remains on the list forever.

I’m really struggling and need some suggestions.

What exactly is an ActiveConnection? How do I close an ActiveConnection? Why would these remain at the customer’s site? What can I look for?

Any suggestions would be welcome.


Where are you pulling the ActiveConnections property from?

@Greg O’Lone - From the Session.ActiveConnectionCount property.

Ok, I think (I have my fingers crossed) that the problem at the customer’s site was that their proxy server was using the same port as my application, namely 8080. So, one for others to consider if they are experiencing the same problem as me.

I have changed our port number to 9001 and, so far, sessions are clearing as expected. Thank goodness for that.

Thank you!

Well that would do it.

It’s doing it again.

Has anyone got any suggestions?

Case 45084

I wonder if you could quit the session in its TimeOut event ? It seems to work here.

I got rid of this problem for good by never using Session.Quit anywhere at all (not in TimedOut, not anywhere), and just letting sessions die a natural death. See Feedback Case 44360.

Thanks Ralph!

A while ago we did have a Session.Quit in the Timeout event but we removed it (i think because we’d seen a previous forum topic on this). But, bizarrely, we still had it in a garbage collect that we’d written ourselves that attempted to clear hung sessions.

We’ve removed it and will give it a go. Fingers crossed (again).

There was a bug in Session Quit a while ago that made it worse. A the time Greg recommended to simply showURL an HTML page so the session dies eventually.

Today the Session.Quit bug is gone, and it is perfectly alright to use it.

[quote=284623:@Michel Bujardet]There was a bug in Session Quit a while ago that made it worse. A the time Greg recommended to simply showURL an HTML page so the session dies eventually.

Today the Session.Quit bug is gone, and it is perfectly alright to use it.[/quote]
This bug reported in Feedback 44360 involved 2016r1.1. I haven’t check it with r2 or 2.1

What you describe in 44360 seems to me very different from what happened before, back in 2013 or so.

To be frank, I am not even sure it is relevant to this thread.

This is what Jim posted that seemed similar to the case I created with a simple that app that exposes the problem:

There is a difference between sessions that do not die naturally, and sessions you tried to quit that somehow get stuck. If TimeOut fires, then the session is not stuck or frozen. Chances are it will honor quit correctly.

At least, that is something to try before restarting the app. Which in Standalone is messier than in CGI.

I think Ralph’s issue sounds exactly like what I’m experiencing. Whether it’s a bug with the quit command in my case remains to be seen. Regardless, the actual bug is that once a session is “stuck”, no further sessions are cleared.

What you describe is sessions that should have died and do not. That is somehow different from calling quit and the session not quitting.

This could be due to mobile clients maintaining the session alive, for instance.

You could try the session.quit in TimeOut that seems to work just fine here first. If it gets stuck, try a showURL pointing to a regular HTML page. That should take care of sessions artificially maintained by a mobile browser. If these two fail, then I see no other way than a restart of the app.

I should say that I have no experience of Windows Server, and there may be bugs specific to that platform I cannot see here.

Hi Michel,

Thank you for your suggestions but I have tried with and without Quits in the Timeout.

My application will run fine for 10 days or so with Sessions opening and being released as expected. But then, for reasons yet to be determined, a session will get stuck. Once that has happened, ALL other sessions remain alive, regardless of which device they are on. That is the problem. This is a bug in Xojo and I have raised this as an issue. Until Xojo fix this, all I can do is try to work out why the sessions get stuck in the first place. I don’t actually care that a single session has got stuck but I can’t live with all further sessions remaining open until the app crashes.

So what is sticking the session? I have tried with Quits in the Timeout and I’ve since removed them. Currently there are no Quits in the application other than from a my own garbage collect where I’m trying to stop the stuck session. This doesn’t work so I’m going to remove it and see how I get on. Remember, the app runs fine for a couple of weeks so it’s a long process.

Fingers crossed.

If I was building this auto-closing session into my web server I would have a timer. It would loop through the sessions and check the last used date vs now and if it exceeds the timeout close the session. Perhaps for one reason or another that timer is getting disabled after a certain sequence of events and subsequent sessions never close.

That being said even if sessions don’t close it doesn’t really mean anything. A session is just some data about the current state of a random browser. It’s not a lot of memory unless you have hundreds/thousands piling up and your Session object is storing a huge amount of data. If a session is never used then what possible harm could there be if its just idling in the Sessions() array?

The performance issue itself is probably lower level than the session abstraction. All they do is when a request comes in is check to see if the URL has a valid session token in it. If so then like magic they tie the details of that request to a specific session. If no requests come in with that session ID then nothing happens.

Now if you use a bunch of server side timers and long running tasks in your session objects then you might be quite concerned about old sessions not being closed. However the crux of the problem there is you have a very low number of maximum concurrent users you can support with or without properly closing sessions. That would be a bad architecture and needs to be addressed.

I’ve got an app running on Windows 2012 Server R2 that did the exact same thing a couple of weeks ago after running fine for over a year, so I suspect it might be related to a recent Windows update. The problem disappeared after restarting the server–fingers crossed ever since.

Way back when Web Edition came out, we wrote a web app and experienced this issue. It was a pretty busy app with 13,000 to 20,000 unique visitors per month. Sessions got “stuck” constantly every day, the memory usage of the app would go up and the app would slow down to a crawl. We had 5 load balanced stand alone instances running and ended up having to restart all of them every night. We had another Xojo developer review our code and he could not find anything that would cause this so we assumed it was a hard to reproduce bug in Real Basic at the time. Over the past few years, we have launched multiple Xojo web apps and some have experienced this and others have not. We have never figured out what causes it in some apps and not others.

For example, we have a web app that was launched in 2013 and we compiled it with the latest version of Xojo around Nov 2013. That particular app did not have the “stuck session” issue and ran from 2013 to the beginning of 2016. We made some cosmetic changes to the app and recompiled with 2015r2.4 sometime around April of 2016 and now it has the “stuck session” issue. Basically, we have to restart it about every 2 weeks (it is not real busy so it takes a while for the sessions to build up). We have no idea what could have caused this issue as it was primarily cosmetic changes that were made to the site. It could be a code change we made but it also could be a bug that exists in one version of Xojo but not another.

We do not want to blame this issue on a Xojo bug. However, it happens enough in our apps to make us think there is something somewhere in Xojo causing it. It would be interesting to me to see a sample web application that demonstrates this “stuck session” issue and how it can be caused by a bug in the programmer’s code, rather than a bug in the xojo framework.

I suspect you will see it often if you use a unique database connection for each session (this is not scalable despite conventional wisdom).