Still in Memory after 2 hours.
After like 18 hours, still hasn’t quit however it didn’t throw a internal server error when launched.
If that’s the case then you most likely have a memory leak somewhere. Check for places in your code where you are storing references to sessions or web control subclasses and make sure they are getting released properly.
@Greg O’Lone The app is a small test app, check it out:
https://dl.dropboxusercontent.com/u/125593/WontQuit.xojo_binary_project
If there’s a leak then it’s a bug.
[quote=228961:@Richard Albrecht]@Greg O’Lone The app is a small test app, check it out:
https://dl.dropboxusercontent.com/u/125593/WontQuit.xojo_binary_project
If there’s a leak then it’s a bug.[/quote]
Heh. Leaks are always bugs. I’ll take a look today to see if I can figure out what’s going on.
Ok, so I just deployed your sample app to Xojo Cloud (since it’s the most readily available Linux web server I have available). I made one small change… that is, I changed the value of Session.Timeout to 5 instead of 30 so it would redirect after 5 seconds:
Self.Timeout = 5Deployed your app and then stopped touching my mouse and keyboard (because even MouseMove events are considered input). Five seconds went by, the browser redirected to the ASPE website. Three minutes later the app quit, and the log says:
11/13/2015 02:32:03 PM - --------------------
11/13/2015 02:32:03 PM - --------------------
11/13/2015 02:32:03 PM - --------------------
11/13/2015 02:32:03 PM - Friday, November 13, 2015 02:32:03 PM
11/13/2015 02:32:03 PM - In App Open
11/13/2015 02:32:08 PM - Session Open
11/13/2015 02:32:08 PM - WebPage Open
11/13/2015 02:32:09 PM - WebPage Shown
11/13/2015 02:32:14 PM - Session Timeout
11/13/2015 02:32:24 PM - WebPage Close
11/13/2015 02:32:24 PM - Session Close
11/13/2015 02:35:06 PM - Session Close
11/13/2015 02:35:06 PM - App Close Event
I find it VERY interesting that your Session.Close event fired twice and I need to look into that. That means that calling Self.Quit inside the Session isn’t actually closing the Session properly because it’s still hanging around long enough to reach the 3 minute timeout.
Except for that, the app did behave the way it was supposed to and the app did quit right after the last session disappeared.
FWIW, I’m also not getting the Internal Server Error that you were talking about at the top of this discussion. The only thing I can imagine is that you’re running into a server configuration issue of some kind.
You may also want to try renaming your app. I was very surprised to find it’s name set to __Template. Being that this is linux and the request has to go through a web server, it could be that the underscores are what’s giving you fits.
Internal Server Errors are not because an app won’t quit - but because it can’t start. This sometimes means you have a process that has hung and the mutex won’t let you start another with the same ID.
Focus your efforts on why your app is getting stuck.
I realize that the app some how hung, however I did get it to happen using this simple test app.
To get it to stay in memory I did:
[code]I Launched my test app in one tab. About 5 seconds later Launched it in a second tab, I closed one tab and the other tab timed out.
The app remained in Memory when I checked around 20 minutes later. This is what I need to solve.
[/code]
I will do more testing and see how long it stays in memory. I’m assuming at this point the Internal Server error is somehow related to this. I will keep you posted
Note the log file it created does not append to it for some reason, so it needs to be deleted before you run it.
@Greg O’Lone
Here’s the latest test:
As of now it’s been in memory over 6 hours.
Launched app in one tab, Then Launched app in second tab, then closed 1st tab. 2nd tab timed out.
Log:
11/17/2015 09:14:32 AM - Tuesday, November 17, 2015 09:14:32 AM
11/17/2015 09:14:32 AM - In App Open
11/17/2015 09:14:36 AM - Session Open
11/17/2015 09:14:36 AM - WebPage Open
11/17/2015 09:14:36 AM - WebPage Shown
11/17/2015 09:14:43 AM - Session Open
11/17/2015 09:14:43 AM - WebPage Open
11/17/2015 09:14:44 AM - WebPage Shown
11/17/2015 09:15:14 AM - Session Timeout
11/17/2015 09:15:23 AM - WebPage Close
11/17/2015 09:15:23 AM - Session Close
Just out of curiosity, are you sure there are no requests coming in that would end up in HandleSpecialURL or HandleURL? I know I’m drawing at straws here, but I can’t really think of much else that would cause what you’re seeing.
@Greg O’Lone
Still in Memory 1 day, 8 hours.
I’m the only one that knows about this app’s url. So no way any other requests could have anything else to do with it.
I haven’t tried launching it again to see if I get the Internal Server error yet. I’m going to give it another day. And the log shows no more activity.
@Greg O’Lone
Still in memory after 47+ hours.
The app won’t quit.
At the end of the day I plan to launch it again to see if I get the internal server error.
[quote=230826:@Richard Albrecht]@Greg O’Lone
Still in memory after 47+ hours.
The app won’t quit.
At the end of the day I plan to launch it again to see if I get the internal server error.[/quote]
I have encountered in the past such CGI apps of mine that stay running for days and weeks, even when they have no session active. I was told that cgi apps were supposed to quit by themselves when they had no sessions, but it was obviously not the case.
Today, as long as it runs fine, I could not care less about the Linux executable never quitting. There seems to be no memory leak.
What counts is that when a user hits the cgi, it runs. The annoying thing in your case is that it does not.
I haven’t figured out what was causing the Internal Error yet. I did get it once with the test app that is referenced above. Then added code to do some logging. I plan on trying to launch it again later today.
In some of my production apps I’ll get a report of an Internal Server error and it turns out it is always in memory, if I terminate it, then the issue is fixed. This is very intermittent.
OK its still in memory after 6 days 12 hours.
I had that damned internal error in my early tests because I didn’t realized that the app has to have some internal workings in order to terminate itself, until Phillip send me the link to their method for updating cgi apps. It is not as straightforward as php updating, because they keep running until something ends them. The session timeout has something to do but in my case it kept running for days.
In my case, as I mentioned, the app was still running and I could not end it because I have not permissions in my hosting but the provider did a reset on the server for me.
While the app was in that running state, I deleted the files from the server, and also I did the mistake of uploading other apps with the same app id. You THIS WAS THE REASON of the error. The original app was still running and the server shows the error if an app with the same app id attempts to start.
The app ID is definitely different.
Forgot to mention that my app is CGI.
I had to change the application identifier in the build section of the shared build settings, and the linux app name in the linux build options in the IDE. For some reason I never looked at the shared part of the build section before.
To terminate the app, either you reset the server or terminate the process with the linux terminal.
Is it still showing an error when you try to display it ? If so, I would kill the poor thing.
No hasn’t shown the internal server error.
In fact I haven’t seen that on my production apps either.
It just won’t unload from memory, even thought it was told to.