Sorry to hear that. I had high hopes for you regarding this because I never see stuck sessions after purging Session.Quit from my project.
I’ve finally worked out what is going on!
The problem occurs if you have an unhandled error in the Session.Close event. This stops the current Session from closing but also prevents all other sessions from closing.
I’ve raised a case with a test app:
<https://xojo.com/issue/45449>
The problem was manifesting itself with us if the user double clicks the browser’s refresh button. What this does is create a Session but the Session.Open event never fires. This meant that none of our classes, including the error trapping class, were initialised. When the close event occurred, errors were thrown to our error trap, but then the error handler then threw another error which wasn’t handled, because it wasn’t initialised.
It’s worth noting that Chrome in particular creates these “phantom” sessions as well if you just type the app’s URL into the address bar but don’t actually navigate to the app. It causes the same problem.
Good catch! My Session.Close event had a place where I wasn’t checking for a nil before closing the database, that could easily have been the problem. I rebuilt the app just now and put it online, I’ll post again if it still runs into problems.
Hooray!!!
I was able to reproduce the session.open event not firing. However, the web app that we have in production that has the “stuck session” issue has the following code in the session.close event:
If mdb <> Nil Then
mdb.Close
mdb = Nil
End If
So, even if the open event does not fire, i can’t see anything in the close event that would cause a problem.
[quote=291434:@Jim Brock]I’ve finally worked out what is going on!
The problem occurs if you have an unhandled error in the Session.Close event. This stops the current Session from closing but also prevents all other sessions from closing.
I’ve raised a case with a test app:
<https://xojo.com/issue/45449>
The problem was manifesting itself with us if the user double clicks the browser’s refresh button. What this does is create a Session but the Session.Open event never fires. This meant that none of our classes, including the error trapping class, were initialised. When the close event occurred, errors were thrown to our error trap, but then the error handler then threw another error which wasn’t handled, because it wasn’t initialised.
It’s worth noting that Chrome in particular creates these “phantom” sessions as well if you just type the app’s URL into the address bar but don’t actually navigate to the app. It causes the same problem.[/quote]
I think you’ve got it Jim. I can confirm that an uncaught exception in the Close event will prevent sessions from closing properly.
Greg,
Could this indirectly have something to do with my Feedback Case 44360, even though that case didn’t involve the Session.Close event handler?
If I get a minute today I’ll check it.
I’m sad to report that my web app got stuck again today, despite putting a try/catch/end try around all of the code in the session.close event (what little there was)…
Have you tried what worked for me? … Removing or commenting out Session.Quit everywhere in your app (even in TimedOut), just letting sessions die a natural death when the framework kills them with default logic.
Yep, I removed all of the Session.Quit statements a while ago.
Which exceptions are you catching?
I just put a Try/Catch/End Try around everything, I’m not doing anything with the exceptions.
This is the entire code in Session.Close:
Try
'Close all pages, it shouldn’t be necessary, but they seem to hang around
for i as integer = self.PageCount-1 downto 0
self.PageAtIndex(i).Close
next
Self.MyContactPage=nil
Self.MyCopyPage=nil
Self.MyIntroPage=nil
Self.MyLoginPage=nil
Self.MyPassChangedPage=nil
Self.MyRegisFinishedPage=nil
Self.MyRegisNamePage=nil
Self.MyRegisPrefsPage=nil
self.MyRenewalFinishedPage=nil
'Clear others
self.NewRegis=nil
self.startdate=nil
'Close the database
if Self.DataDB<>nil then
self.DataDB.Close
end if
self.DataDB=nil
Catch
End Try
Ok, but you do understand that if the exception were to occur somewhere near the top, say in that loop, that the database object would never get set to nil, right?
You might wan to catch them separately just to see what’s triggering so hat you might be able to handle it better.
[quote=292508:@Greg O’Lone]Ok, but you do understand that if the exception were to occur somewhere near the top, say in that loop, that the database object would never get set to nil, right?
You might want to catch them separately just to see what’s triggering so hat you might be able to handle it better.[/quote]
Ah, good catch! I’ll put them in separate statements and see what happens.
Thanks!
I’ve also noticed that if the user closes the browser, the Session closes before the WebPages do and if you have an unhandled error in the close event of the page, then the sessions also get stuck.
@Greg O’Lone - Has this fix made it into the next release and do we know when that’s schedule to be released?
A fix has been submitted, but we do not discuss release schedules here.
That said… you still need to do exception handling in your code… and allowing it to fall back to Session.UnhandledException or App.UnhandledException is not considered handling it. that’s a stopgap measure to keep your app from crashing, but you should be figuring out what causes the exception and either change your code to avoid it, or wrap your code in a try/catch.
It’s also very important that you guys/gals test this change when we get to beta. It passes our tests and fixes the bug represented on the case, but we’ve discussed more possibilities since then for which I don’t have samples.
@Greg O’Lone [quote] … but we’ve discussed more possibilities since then for which I don’t have samples.[/quote] Should I add another example app to the Closed case about the Form.Close event causing the sessions to stick?
No. adding things to a closed case will not get them looked at. Please just try it out in the beta when it becomes available.
My Sessions are still sticking and basically it appears that if there is an unhandled exception is any page object (e.g. a button or label etc.) after the Session has closed, then the Sessions stick.
I’ve created a new case with examples here. If this is a duplicate to the previous case, my apologies:
<https://xojo.com/issue/45565>
I’ve also checked to see if an unhandled error during a procedure after the Session has closed causes the problem and while this makes the Session hang and not be released, it doesn’t seem to prevent other Sessions from closing.
@Greg O’Lone [quote] Please just try it out in the beta when it becomes available.[/quote]
We are firefighting here so waiting until another round of testing and releases is going to hurt. Please can you check that your fix sorts all of these issues.
Thanks for your efforts.