I used to have stuck sessions way back in 2013 with one of my apps.
Now every night, around 3:00 AM EST, it looks at the current sessions, and if there is none or only sessions that have overstayed beyond their TimeOut (easy to keep track of), restarts.
@Brandon Warlick. I’ve never been able to make a session stick in a demo application and I’ve tried very hard! I can make a session hang by running an infinite loop but this doesn’t stop other sessions from clearing. One thing that does seem to stick the session is the web app shares the same port as the proxy server. Sessions stick quite quickly in that scenario. So maybe it’s a networking issue.
To me, I don’t care why the session hangs or gets stuck, what I care about is that no further sessions will close and they just build up until the app falls over. This is a bug in Xojo in my opinion. That should never happen.
Also, if your app was working fine for years in one version and then gets stuck when you recompile, that points at an issue with Xojo.
@Seth Ober. Interesting about the Windows Server update possibility. I will investigate that.
Thanks to all for your thoughts. I was under the impression that this was an isolated incident but clearly it is not.
@Brandon Warlick If you have kept the version of the code that was compiled with 2013 (before small changes) it would be a nice to compile that old version with new(est) release you have on a separate instance, and then see if hanging sessions appear. In such a case, we could all say that it is an issue Xojo should fix.
It’s a thread actually but the concept is the same. I’ve looked long and hard at this situation to figure out why some of you are experiencing this issue.
To clarify, Session.Quit just sets a Boolean flag on the session so that it will get dropped on the next loop regardless of its state. Here’s the thing though… All we can do is to drop all of our references to the session and assuming your code doesn’t hold any more refs, they’ll get dropped the next time things are released. We do not do anything differently as time goes on so the only thing I can think of is that the release thread is getting starved of cpu cycles somehow.
The only times I’ve been able to reproduce this myself is to set up an unyielding tight loop or thread, but that also typically makes the app really slow. Well, that and when your app runs really close on memory and the server starts paging.
@Greg O’Lone Greg, the problem isn’t that the session won’t close, the problem is that it stops all other sessions from closing. That is the problem that we’d like sorted. Can you look into that one please?
Thanks
Jim
How do you do make the app restart itself?
The app I uploaded with Feedback 44360 is a simple app that reproduces the stuck session causing all other sessions to stay stuck. It’s very simple. It has 2 buttons. One calls Session.Quit and the other calls a MsgBox that shows SessionCount. That’s it. All it takes to produce a stuck session that causes all other sessions to be stuck is to run the app on 2 devices and then, on one of those devices, periodically press the Session Count button to see the Session Count and then Press the Session Quit button and then reload the browser. For this test, you need the app running on more than one device. The last time I tested that out, it took 17 cycles, performed over 5-10 minutes, using Xojo 2016r1.1 on a MacbookPro, to get all sessions to be stuck.
In CGI it is simple as pie since you simply stop it.
For a standalone, I believe Launching a bash script that starts the app before you quit should do it. Or use a helper.
I just looked at the sample on that case and it doesn’t really tell us anything. SessionCount doesn’t reduce until the session actually gets destroyed, and by default that takes 3 minutes. Following the instructions on the case and then reducing down to a single session and waiting for 3 minutes, the msgbox ultimately shows:
Session Count: 1Which is exactly what I expect to see.
Yeah. There’s nothing special about that app. It just lets me see the problem if I cycle through the steps outlined, many times. What I would see in MsgBox would be “Session Count: 2” after each cycle of those steps (in much less than 3 minutes, if I remember correctly). But then, after a number of such cycles, I stop seeing the Session Count drop to 2. You should never see the Session Count drop to 1 unless you’re running this on just one device. If I do this on only one device and cycle through those steps, I found I couldn’t produce the problem. I mentioned that in one of Feedback replies to my case. To produce it, I needed two devices, so I had my Android phone holding on to one session while I cycled through the steps on my Macbook Pro. The last time I tested this, it took 17 cycles to produce the problem. Once that happens, no matter how long you wait, the Session Count never drops.
Maybe related to the problem I reported I while ago (or even the same?): https://forum.xojo.com/29942-web-app-leak-sessions-not-terminated (in the Pro forum - could be moved to public) & https://forum.xojo.com/28708-websession-close-issues
My Feedback Case 44360 is now verified and fixed as of today, according to Greg O’Lone. Perhaps this addresses your problem.
@Greg O’Lone Is there any chance that you can let us know what was causing the “stuck” sessions? If this is something that has been in the framework since the beginning, this would be an incredibly important bug fix, at least for me.
@Greg O’Lone You’ve marked these issues as verified and fixed! That’s fantastic news. Thank you and everyone at Xojo for persevering on this. It was a tricky one. My apologies if my frustration came through.
I’m looking forward the next release with great anticipation.
Jim
Unfortunately this problem falls under the category of not being able to reliably reproduce and not being able to see it at all when debugging. So basically we’ve refactored the code to be slightly more efficient.
To set your expectations, this work was done after we reached the cutoff for new items on r3, so this change will not be in this next release.
When we do reach the r4 testing cycle, I encourage all of you to test this code thoroughly and as early as possible.
@Greg O
So it sounds like you haven’t actually reproduced this or fixed it.
I feel that because:
This all suggests to me that we are hitting a resource limit.
But:
Might this be a networking resource or a database resource that’s causing the problem? These are areas that I can only speculate on and we could use your insight.
Also @Ralph A seems to be able to reproduce this consistently. Perhaps you need to persevere with this?
Well, we won’t know if I’ve fixed it until the next testing cycle, but we did refactor the code for efficiency and debuggability(?). In our tests, the sample that was attached to that case no longer shows the problem, but as I said, the ability to reproduce the problem varies from day to day and machine to machine.
@Greg O’Lone [quote]In our tests, the sample that was attached to that case no longer shows the problem[/quote]
Ok, well that sounds very promising. I’ll put my positive head back on and look forward to testing r4.
Thanks again.
[quote=284618:@Jim Brock]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).[/quote]
Jim,
Have you seen stuck sessions since purging your code of Session.Quit? It’s been over 3 weeks since you did that.
Yes, the sessions are still getting stuck after removing Session.Quit