Some time after it was reported 
Some might consider that to be a bit vague and not very helpful. 
its friday
some have plans for the âweekendâ beyond âwork all weekendâ
the bug was just reported 2 days ago
we already have long lists of things to get done
Iâm not sure that anyone even has a full analysis of the bug or a plausible patch for it
its a realistic answer at this point
[quote=115106:@Norman Palardy]its friday
some have plans for the âweekendâ beyond âwork all weekendâ
the bug was just reported 2 days ago
we already have long lists of things to get done
Iâm not sure that anyone even has a full analysis of the bug or a plausible patch for it[/quote]
Thatâs a much better answer than:
But both say âlaterâ - one just says why - but still not âwhenâ
But if thatâs better Iâm OK with that 
I know Greg knows about this (since he replied) but Iâm pretty sure thereâs no definitive âfixâ ascertained yet.
My observation with this issue and the workaroundâŠ
If I add ShowURL âabout:balnkâ to the session.timedout event, I believe the session will terminate as desired.
If, on the other hand, I close the browser tab while the session is active - I donât believe the session terminates. To address this I put ShowURL âabout:blankâ in the session.close event - and that did not fix the issues.
In all cases, whether or not the session closed, the does not seem to close, even though I have App.AutoQuit = True and App.Timeout = 30.
Unfortunately, this is a serious issue for me, and I can not find an acceptable workaround.
Hopefully the fix for this issue (34438 - WebSession âghostsâ chewing up memory) will provide an acceptable solution.
Should say "âŠnot the session closed, the APP does not seem to close,âŠ
Putting the ShowURL code in session.close is meaningless. When that event fires, the browser is already gone.
Setting App.timeout does nothing for you if there are sessions remaining. That value sets the number of seconds that the app will wait after the session count goes to zero before it quits.
The amount of time between a browser leaving or closing until the session dies off is 3 minutes. There is no property that you can set to change that value.
Having said all that, are you saying that sessions are not dying off after 3 minutes?
Understood. And yes, though I feel that I need to confirm more thoroughly, it appears that if the session doesnât time out on its own, it will not close. And it further appears to me that the app never closes. But like I said, more confirmation is warranted.
Now Iâm really confused. Is this not what I said was going to happen up above when I made the suggestion to use ShowURL instead of Session.Quit? Session.Quit is definitely broken at the moment. Iâm not sure why yet, but it definitely is broken and not properly closing sessions. That in turn causes the app to not quit (because there are sessions still open).
I guess ALL the scenarios werenât clear to me as we didnât explicitly call them out. I was hoping there was away to apply the workaround (point browser to another URL) to address the issue for all scenarios - but it only applies for when the session times out. My discovery: canât do anything about situation where user actually closes browser before session times out.
Then, I was hoping that for when the workaround does apply (i.e. all sessions were closed by timing out) that the app would close on its own. My discovery: This is the part that needs more study, but I am not sure the app closes even after all sessions close.
[quote=115339:@Mark Pastor]I guess ALL the scenarios werenât clear to me as we didnât explicitly call them out. I was hoping there was away to apply the workaround (point browser to another URL) to address the issue for all scenarios - but it only applies for when the session times out. My discovery: canât do anything about situation where user actually closes browser before session times out.
Then, I was hoping that for when the workaround does apply (i.e. all sessions were closed by timing out) that the app would close on its own. My discovery: This is the part that needs more study, but I am not sure the app closes even after all sessions close.[/quote]
I just checked my site. I had an application with two processes running : one from July 25 running for 92:36 hours, and another for 5:30 hours. I wonder which user could keep active for 92:36 hours. I killed the processes, but I wonder : which user could stay active for two days ? A misconfigured robot ? It is a mail sending page. Could it be some spam collector polling the page ? Any normal user will have sent the mail in one hour tops. I am thinking on adding to the TimeOut a timer which will disconnect a user who stays active for over an hour by moving him to an HTML page.
[quote=115339:@Mark Pastor]I guess ALL the scenarios werenât clear to me as we didnât explicitly call them out. I was hoping there was away to apply the workaround (point browser to another URL) to address the issue for all scenarios - but it only applies for when the session times out. My discovery: canât do anything about situation where user actually closes browser before session times out.
Then, I was hoping that for when the workaround does apply (i.e. all sessions were closed by timing out) that the app would close on its own. My discovery: This is the part that needs more study, but I am not sure the app closes even after all sessions close.[/quote]
Are we talking about your app, or the sample that was provided with the Feedback case?
Both - I believe. Because I still have a remnant of my test app remaining in memory for days now. But like I said, and my apologies for this, I am not sure my observations have been scientifically controlled well enough to be conclusive - more time needed, and I have been swamped - I may be able to do some better testing later today.
I just noticed I have 100âs of sessions still open in my current live app because of this issue 
Not good. Iâm going to force reboot it nowâŠ
Twice this year my app stopped launching around 49 sessions. Was not pretty.Phillip Zedalis helped me out the first time and since I learned how to kill the processes.
I have implemented the TimeOut and the issue is not as severe, but yet, some zombies persist as the two I found this week.
In addition to not going away, my app generates a LOT of myapp.cgi commands on the server - each consuming 30-40MB of space. One of my users has been on for about an hour, and there are now 35 of these commands alive on my server - they never go away unless I manually kill the app. Given the other issues, it is very difficult for me to assess the source of the issue.
In my mail app it is pretty obvious that a user online for one hour has no business doing so. Apart from a bug, what could keep a session active beyond the TimeOut setting ? In the case of my user stayed two days it is absolutely certain TimeOut was not honored. Maybe the radical option would be to do an App.Quit once a day at an hour remote enough to minimize chances that a user gets hit by that, like 3:00 AM ? Would it kill the zombies ?
I like that idea - assuming App.Quit works. I can even automate notice to users.
My problem as mentioned above, is my app generates so many myapp.cgi commands, and associate httpd commands, that it only takes an hour or so to saturate the server memory. I have two apps - one is multipage the other is pretty much single page. They both generate these commands without any interaction. I can not figure this out - I may have to change service providers as a test to see if that changes anything.
There seems to be a relationship between these commands being generated and a ghost remnant of the app being resident, but it takes much more time than I have had to drive that to conclusion.
Are all these requests originating from the same IP ?