CGI app websessions don't die

Is this a known issue?? Have tried compiling with 2014r2 & 2014r2.1

I have a cgi web app running on 1701 host Linux server, and when users finish using my app, and close their browser window or tab, the underlying session does not die and its Close Event is never called. Even after several hours, the unused sessions are still there.

Testing the app locally on a Windows machine using the IDE “Run” button (or building a Standalone exe and running it) produces the correct behaviour.

Any ideas?

I suppose that you did, but have you looked into using the timedout event? A simple self.quit statement in the timedout event of your session object should work.

In the session.open event, I have also this statement: self.Timeout = 300. You can set the number of seconds that you prefer. I think 5 minutes is OK.

hope this helps.

LD

[quote=121611:@Louis Desjardins]I suppose that you did, but have you looked into using the timedout event? A simple self.quit statement in the timedout event of your session object should work.

In the session.open event, I have also this statement: self.Timeout = 300. You can set the number of seconds that you prefer. I think 5 minutes is OK.
[/quote]

According to Greg O’LOne, session.quit in 2014R2 has a bug and it is better not to use it, but rather to redirect the user to an HTML page, so the session dies by itself.

I had such ghost sessions in the past, and since I have implemented TimeOut and the redirect to an HTML exit page, they are gone.

I have tried both solutions with Session.TimedOut event. ie redirecting to another URL, and tried self.quit.

Both solutions work fine with Standalone app, but neither solution is working on my cgi app on Linux server.
<>
After further testing, this is what I have found…
Redirecting to another URL directly from the Session.TimedOut event DOES WORK! (So far…).

My web app originally had the Session.TimedOut event call a modal webdialogue which contained a countdown timer. This would allow the user time to Continue Browsing if he clicked a button, or it would then call a redirect to another URL if user failed to respond. This set up works fine for Standalone, but session never dies in cgi app.

I will keep testing… but for sure there is different behaviour between Standalone and cgi app builds.

Just out of curiosity, do you use control arrays?

No Greg. No control arrays in this app.

Cannot fathom what is wrong. In my Session.TimedOut event I have 1 line of code only: ShowURL… etc.

If the user leaves his browser inactive, then after the timeout period expires, he will see the exit URL displayed… But the original session does not die, the session.close event does not fire - even after 30 minutes.
BUT just occasionally it does work! Out of around 20 abandoned sessions I am seeing 1 or 2 which do fire their close event. How odd?

If I run the same app as Standalone on a Windows machine, I see the close event fire every time as expected.

For my cgi deployed app I am using 1701 to host it. My Session Open event writes a record to a “SessionLog” table. Every user interaction with the app’s menus also writes a record to the SessionLog. the Session.Close event writes a record to the SessionLog. If I examine the SessionLog after a few hrs of operations I see each browser session “Open” and I see every menu event triggered by the user. Every session “should” end with a Close Event log, but I am seeing around 90% of sessions that never show the Close Event.
As for the 10% of sessions which DO list a Close Event in the log appear to be random - ie user may/may not have accessed certain menus - the browser platform can be anything from Windows / Android / Mac - the browser can be any.
In short, there does not appear to be any defining feature, or reason WHY these particular sessions did close correctly.

You can see this for yourself live if you open my Monitor app and then in another tab (or browser), open the web site . Switch back to the Monitor and you will see your session Open event listed at the bottom of the list. Click on your session to view Activity. If you then close the web site tab (or if you leave the web site inactive for 5 minutes until it times out to the Exit message, you should then see the close event in the monitor around 3 minutes later - But chances are, you won’t!

Very odd - It all works perfectly in Standalone!

I’m curious. If you make a completely empty project, do you encounter the same behavior? No controls, just the logging code.

I’ll give that a go Greg.
Will let you when I have something…

Mmm, interesting!

I have built a test app which generates Open / Close events etc. You can also monitor the live log with this app as before.

Well the test app seems to perform perfectly, but then again, the production app does also work ok for a while. It seems that the production app’s session.close event works for a while following an App Quit / Restart. But after a while the Close Event stops working, and then will never work at all until the next reboot of the App.

What’s the difference between the production app and the test app? Well quite a lot, of course - but some thoughts are:-
Test App
Close event code calls a method (located within the Session object). That method then calls the log writing method, then calls ShowURL.
Production App
Close Event code calls a method (located within the Session object). That method then calls various database actions to tidy up, then calls the log writing method, then calls ShowURL.

Test App
Session object contains just 1 SQLitedatabase object (SessionLog) stored as a property of Session.
Production App
Session object contains 3 SQLitedatabase objects stored as properties of Session, plus 3 RecordSet objects stored as properties of Session. The method that is called by the Close Event does not explicitly close the recordsets or databases - should it???

[quote=122013:@Tony Davies]Mmm, interesting!

I have built a test app which generates Open / Close events etc. You can also monitor the live log with this app as before.

Well the test app seems to perform perfectly, but then again, the production app does also work ok for a while. It seems that the production app’s session.close event works for a while following an App Quit / Restart. But after a while the Close Event stops working, and then will never work at all until the next reboot of the App.[/quote]

You may try to have your app entirely quit everyday, at an hour chosen to be as little inconvenient as possible, like 3:00 AM. It will restart automatically when a user gets the cgi URL. That should kill the ghosts.

Something to look for: do you have references to any of those database connections or recordsets in use anywhere else in your app? Even references to WebControls would cause sessions to stay open.

Greg, could you clarify more? I do have a number of WebContainers which contain Methods that interact with those database connections & recordsets. What do you mean exactly by references to webcontrols?

My Session object also contains a SMTPSecureSocket as a property. Several methods in various WebContainers refer to that Object.

Also, I have some webdialogs which contain a reference to a webButton (used by the dialog’s dismissed event to determine which button the user clicked).

I think you are on the right track here - something in my app is keeping the session live, sometimes!

Well, basically if you’ve got properties in other classes which reference properties or controls in a session, the session itself has a record of all of the controls which belong to it. What I’m describing is called a “circular-reference”, and what happens is that neither of the classes can ever be destroyed because they are holding references to one another.

Here’s an example… you create a subclass of a WebLabel and make a property called MySession as WebSession. When MyWebLabel is created, you set MySession = Session(). An instance of MyWebLabel is placed on a WebPage.

Now when the user leaves and their session is “released”, it can’t be destroyed because MyWebLabel has a property that points to the Session. MyWebLabel will also not be released because the Session itself holds a reference to each WebPage and WebPage1 holds a reference to each of its controls. Boom no Session.Close event because it hasn’t really been destroyed.

Many thanks for taking the time to explain that Greg. OK, I will try and get my head round Circular References.
I think we are making progress. Last night I studied all my Methods, and found 2 which contained RecordSet objects created from one of the Session database connection references, which I had accidentally forgotten to explicitly Close at the end of the Methods.

Then, between 07:43 this morning until around 13:30 the log showed 100% reliable Close Events. Sadly they stopped working since…
I think this may indicate that I have fixed some of the circular references, but I guess there’s still at least one lurking somewhere!

Is there a tool for tracking down Circular References? The Analyze Project utility does not show anything odd.
Why does the app work ok in standalone mode?

Anyway, thanks again for your help!