I am experiencing different behaviour between a build and a debug run when a session’s close event is called.
In this event, I write a timestamp to a sqlite database. This works fine while debugging, however the compiled app does not perform that database action.
Any idea what might be happening or how to ‘debug’ without the debugger?
Anyone?
Have you checked with system.debuglog if the event actually takes place or if it is an issue with the database ?
Have you tried moving that to CancelLoad ?
Does DebugLog work with a compiled web application? I thought it’s just for debugging.
CancelLoad exists only on the desktop HTMLViewer AFAIK.
[quote=236657:@Alex von Siebenthal]Does DebugLog work with a compiled web application? I thought it’s just for debugging.
CancelLoad exists only on the desktop HTMLViewer AFAIK.[/quote]
Yes, it works, and sends the message to the Console. It is probably the best debugging tool in 64 bit so far, short of full fledged run.
Sorry for CancelLoad, you are right, it does not exist.
Now, are you closing the session yourself, or are you waiting for it to close ? Maybe you could use TimedOut which happens before Close.
At any rate, it seems like a good idea to verify which events actually fire.
Just out of curiosity…
Just FYI, and I know this causes some confusion because I have to explain it a lot…
The Session.TimedOut event only fires for user inactivity. It is based on a timer on the browser which looks for mouse and keyboard activity, and it is deactivated when the browser receives the Close message.
Okay, it happens on OSX in Debug mode as well, not so on Windows. No difference between 32/64 bit.
Right now I have a destructor in the session object that does DB cleaning/logging. But it seems like the DB property (in the session object) goes NIL too early.
Is that the intended behaviour? If so, how would one do clean up stuff if not in the destructor?
[quote=243977:@Alex von Siebenthal]Okay, it happens on OSX in Debug mode as well, not so on Windows. No difference between 32/64 bit.
Right now I have a destructor in the session object that does DB cleaning/logging. But it seems like the DB property (in the session object) goes NIL too early.
Is that the intended behaviour? If so, how would one do clean up stuff if not in the destructor?[/quote]
Use the Session.Close event for writing to your log and releasing your database connection. The Destructor fires some time after that.
I did that, however that doesn’t work reliably either.
what does “doesn’t work” mean in that context. Unless you’re explicitly closing your database connection and setting it to nil somewhere in your app, it’s hard to see how this is possible.
Also, Just out of curiosity, where is your database connection defined?
The database connection instance (sqlite) is a session property (part of a larger ORM). It’s created in the session.open event and in its close event, I write to the database to do the logging and cleanup. However, those db operations randomly work. On other occasions, they are skipped. There’s no error, after all…
Should I move that code to a thread and assign it to an app property?
No. It really should be in Session.
If you’re opening a connection every time you need to access the database, add some spammy logging with System.Debug which checks the state of the connection after you call connect.
Make sure you check the LastErrorCode, isWritable, and isreadable properties of the folderitem to make sure you’re allowed to do that.
It’s worth noting that with cgi, it’s not uncommon for your app to run as a different user, and may not have the permissions you think it does at runtime.
Strangely, it seems totally random. Behaviour differs between debug and compile, between OSX, Windows and Linux. Even then, I can’t see a stable pattern and it’s hard to isolate the root cause because of the entire complexity (large app, large ORM, different environments and so on…). Otherwise I’d have reported it in Feedback.
The connection is opened once when the session is initiated (standalone mode). I do check all these properties and raise
exceptions for those cases. When that happens, the debugger kicks in and in some occasions, the database object would report an error that it couldn’t prepare the statement. A few clicks later in the debugger (checking variables, no changes), it would report the database is NIL (in the ErrorMessage, not an exception). It doesn’t happen in any other place of the app, so I am left puzzled.
I guess I’ll have to put the issue aside until I find better clues of what’s really going on.
Getting closer to the problem!
It seems like at some point, the sessions are simply not closed anymore. I have a button that calls “Session.Close”. If I freshly upload the app and browse it with my Mac, it all works fine. As soon as I first use my Windows with IE, the button’s code doesn’t quit the session. While the browser displays the usual “session quit” message, the session stays alive in the background. As of then, the same happens even if I use my Mac with Chrome.
What’s going on with Windows/IE that it prevents all sessions from closing as of first use?
I can tell you that there is nothing different about the framework when it comes to any particular platform/browser. As a matter of fact, I spent a great amount of time tracking down and fixing memory leaks in the web framework a few years ago (server and client side).
I’d like to clarify though… If you want to force a session to close, you need to call Session.Quit. When the next cleanup process comes around, the session will be closed and references removed for eventual cleanup by the OS.
If you can replicate the behavior you are seeing in a simple project, I’d love to see this in action as I’ve not been able to reproduce this yet.
[quote=245836:@Greg O’Lone]
I’d like to clarify though… If you want to force a session to close, you need to call Session.Quit. When the next cleanup process comes around, the session will be closed and references removed for eventual cleanup by the OS. [/quote]
The point is: that is not happening, even though I do call Session.Quit.
[quote=245836:@Greg O’Lone]
If you can replicate the behavior you are seeing in a simple project, I’d love to see this in action as I’ve not been able to reproduce this yet.[/quote]
I opened a new thread for that purpose, please see:
https://forum.xojo.com/29942-web-app-leak-sessions-not-terminated
I am happy to get in touch with you via email if that helps you and speeds things up - it’s a potentially disastrous bug when sessions don’t get released but accumulated - and I urgently need a workaround.
Perhaps trying showURL ("about: blank") instead of session.quit?
On the client side, the framework is destroyed. On the server side, the session should be automatically destroyed after a while.
[quote=245853:@olivier vidal]Perhaps trying showURL ("about: blank") instead of session.quit?
On the client side, the framework is destroyed. On the server side, the session should be automatically destroyed after a while.[/quote]
Doens’t work either, unfortunately. The Session.Close event is never called.
I used your project. On my PC (win10, Xojo 2015R4, build 32bits), I opened a session in four browsers (chrome, opera, edge, IE11). On android, I opened a session with chrome mobile. On another PC (Win10), I opened a session in firefox and edge. All devices are on the same local network.
After about 10/30 seconds, on a single browser, I leave all sessions by pressing “terminate selected session” (except of course this session).
About a dozen tests, I replicated the problem once, from IE11. Me too, I do not know why the sessions are not closed during this test, while I did not have problems with other tests (even with IE11).
Happy that I am not silly 
I could only reproduce it reliably for compiled apps - while the point in time when the entire hocus-pocus begins still seems random.