I can do that, but the simple fact of the matter may be that there is no solution for you until the next release.
I’d like to know though… do you know why are you getting exceptions after the session has “closed” ?
@Greg O’Lone
Sorry, I wasn’t expecting a fix from you before the next release. I just didn’t want there to be a release and then discover there were other scenarios that I knew about that hadn’t been considered.
Initially we had an error handler class that recorded errors in our error traps. The class was referenced via the Session and the (wrong) assumption being that the session wouldn’t be nil when an error was raised. But we also have configuration items at the Session level, so, if the Session becomes nil because the user has hit the refresh button, or simply closed the browser, then we had this sort of scenario:
Try
Dim S As String
S = Session.Outline.ConfigurationItems.GetConfigurationItem("ImagePath")
Catch Err as RunTimeException
Session.Outline.DisplayError Err
End TryReferencing the Session inside the Try block throws the first error, but then referencing the Session in the Catch throws another, unhandled error. We have changed this throughout our code so the errors are not unhandled. We are actually going to change our error trapping paradigm completely based on this situation.
This situation happens more when the system is under load because routines may take longer than normal, and users get bored and hits the refresh button. The session goes to Nil while another thread is still running, we try to reference the Session within that thread, and over she goes.
It begs another question which is, why does the Session go to nil before all the forms and containers are closed?
Thanks
From your question, it sounds like the primary issue is that the Session goes Nil before the WebThread completes and that is completely true. To prevent memory leaks, references are kept in a downward direction, but not up. What this means is that a Session has hard references to the pages it contains, and pages to their controls, but not the other way around. That means that if you have a WebThread running that’s connected to a WebPage, the page could certainly live a little longer than the Session it is associated with.
Oh, and that’s an important distinction WebThreads are not owned by Sessions, they are just associated with them. What this means is that code running in a WebThread has a way to figure out which Session it was spawned from, but it’s certainly possible that the Session could go away with no notice.
I’ve recompiled my app with R4 and it still sticks the sessions. All the test apps now run Ok. However, when I run my production app, it will go for a few days and then a session will stick.
Just to re-iterate, the problem is NOT that one session sticks. The problem is that it prevents all the other sessions from closing. Having fixed the problem with unhandled errors, is there any other scenario that could cause the same thing?
I’m at a complete loss as to what to do next.
The big red button solution would be to relaunch the app.
@Michel Bujardet - Thanks for the suggestion but unfortunately, this is a 24/7 application running the Accident and Emergency system at 4 major hospitals in the South East of England. It needs to stay up. The support staff currently launch another instance of the application and point new logins to that when they see a stuck session but this isn’t really an acceptable solution as they have to watch, 24/7.
What would be nice would be if we could kill a stuck session. I requested this feature but it was immediately dismissed. So, I’m back to square one.
Have you checked the database for locks? Thats something I’d look into.
A quick read suggests your focussed on Xojo for the source of the issue - could it be at the database level? Your contacts at the NHS should have a DBA looking after the database maybe they could run some checks for you when the scenario manifests - see if there are any locked resources.
There are plenty of system tables to help grab that info.
Could you be running into a deadlocking scenario or simply a block? I haven’t read the whole thread but don’t underestimate the role SQL Server 2012 could be playing.
[quote=302927:@Jim Brock]@Michel Bujardet - Thanks for the suggestion but unfortunately, this is a 24/7 application running the Accident and Emergency system at 4 major hospitals in the South East of England. It needs to stay up. The support staff currently launch another instance of the application and point new logins to that when they see a stuck session but this isn’t really an acceptable solution as they have to watch, 24/7.
What would be nice would be if we could kill a stuck session. I requested this feature but it was immediately dismissed. So, I’m back to square one.[/quote]
Sigh
We refactored the entire Session cleanup mechanism (again) with your report, and I’m very disappointed that we’ve not fixed your problem.
Just for clarity, the reason your request was declined was that calling Session.Close already does this in that it puts the session into a queue to be removed. On the next cycle (which is 15-30 seconds later) the session runs its cleanup routine and is removed from all of the master lookup tables. These are all things that must happen for the app to remove the session properly and not have any memory leaks… and yet it sounds like you still are.
Jim, have you tried clearing your browser cache? I was experiencing a ton of issues during web app development including persistent data and apps not reflecting changes I had made. Once I cleared the cache in Safari,boom! everything was back to normal. I don’t know if this is going to work for you, but give it a go.
@Greg O’Lone - Your efforts are appreciated. I can’t believe that your fixes have made no difference. I keep checking to make sure we are using the newly compiled version. But, the business owners are now screaming at me and I don’t have any answers.
@Patrick Delaney - Yer, I have looked at the database for locking and blocking and we have lock timeouts on all our calls. The NHS DBAs have given us permissions to run a variety of admin processes for us to check what’s going on but we haven’t pin pointed anything with this. We also had a lot of fun with error handling and we use MonkeyBread’s ODBC plugin as this is the only option that handles BLOBs, errors on multiple recordsets, and lock timeouts. I haven’t ruled out the database side as causing the initial session sticking. But, as previously mentioned, the problem is not that one session sticks, it’s that it prevents all other sessions from closing.
@chris benton - No, we don’t clear down the browser cache so I’ll look into this and give it a go. Thanks for the suggestion.
Thanks to everyone for your help and suggestions.
If you were using cgi, you could quit the app and it would automatically restart at next request, so when you detect a stuck session you can quit to refresh the app.
With Standalone, it would be possible to use a dispatcher whose sole purpose would be to dispatch users to identical App A or App B. If App A has a stuck session it sends an IPC notice to the dispatcher to requests a restart, and quits (if it does not have other clients).
Then the dispatcher sends all users to App B, it restarts App A, and so on.
Of course the big issue is to detect stuck sessions from within the app itself.
@Greg O’Lone - Is a session actually a type of a thread or a subclass of a thread?
I’ve considered setting up haproxy to handle this sort of thing. I have an app right now that still runs on an older version of code, but it occasionally gets locked in a state where it consumes 100% of a cpu core.
The idea would be to have haproxy use a check url which the app would respond to based on it’s own internal test. If it’s using to much cpu or has a hung thread or whatever it would give a negative response at which point haproxy would stop sending requests to it. Then after a timeout or some other condition the app would kill itself or have a shell script kill it and then it would respawn and the haproxy check would add it back to the rotation.
This sort of solution would be kind of specific to the particular app depending on what kind of checks it needed.
I’ve always suspected that the standalone apps could get hung up if bad data was thrown at them, but I’ve not been able to prove it or catch it happening. I do know that Chrome could give a standalone app fits with the way it opens so many connections so fast, but I think that has been corrected. If I ever get time to update my app that has issues I’ll try to check everything again on the new version of Xojo and see how it behaves.
No. WebSessions are a standalone class. It’s the requests from the browsers themselves that are WebThreads.
@Greg O’Lone - Greg, I think I’ve asked this before but what is an “ActiveConnection”? There is an ActiveConnectionCount property on the Session and when the sessions stick, this count never goes to zero. Would this stop the session from closing? How do I close an active connection?
Some clarification would be appreciated. Thanks
[quote=303338:@Jim Brock]@Greg O’Lone - Greg, I think I’ve asked this before but what is an “ActiveConnection”? There is an ActiveConnectionCount property on the Session and when the sessions stick, this count never goes to zero. Would this stop the session from closing? How do I close an active connection?
Some clarification would be appreciated. Thanks[/quote]
Just like the docs say, it’s the number of connections that are currently interacting with a session. So let’s say a user uploads a very large file which takes an hour to upload… the ActiveConnectionCount property will be at least one while the upload continues. And yes, an upload can prevent a session from closing on its own, but I have my doubts as to whether it would keep a session that you specifically told to close from closing. I haven’t tried it though.
@Greg O’Lone - Thanks Greg. We do have a file Upload facility in our application. Perhaps that’s go something to do with it. I’ll take a look.
Still struggling with this. We are using IE11 and there’s an horrendous memory leak in IE11 at the client. After an hour or so, the memory runs out and IE falls over. This is when we see sessions which are logged out, all pages closed but still with an active connection. We have reproduced the sessions doing this in our an dev environment but not to a point where it stops all the other sessions from closing. In our dev environment we have to endthe task on IE to close the browser and the connections remain for about 5 mins but do eventually close.
Is anyone else experiencing this problem? @Greg O’Lone - Might this cause the sessions to stop clearing altogether?
We are moving the users over to Chrome to see if that alleviates the problem (not trivial in the NHS!). I’ll post how that goes.
If IE is still running in the background, it’s certainly possible that it’s still communicating with the server and keeping the session going.
@Greg O - Sorry, I’m not talking about a single session. Could these sessions that are still trying to communicate stop all the other sessions from going?