Life of a sessionID

[Richard I]

Hi,
can you please clear up a query...
When a user logs into a NT app,  a sessionID is created.
When another user logs in another session variable is created.
etc
The Question is:
What happens to these variables?
Do they last as long as the app is open or
as long as the browser is connected?
or until timeout?
Does one overwrite the other?
Could they be consuming memory if the app is not closed

Thanks
Richard
NT 8.71

[bshields]

Hi Richard,

They last for as long as the session is active, plus the session timeout. When the session timesout the session and all its data is released.

There is a session timeout value in the template that controls this.

Regards
Bill

[DonRidley]

What happens to these variables?

I tend to think to think of the Session ID as a GUID for the new thread created by a user logging in to the app.  A new session ID is generated for every login.  The session stays "alive" for as long as the user stays logged in or the timeout occurs.  Once one of those two things happen, that thread, and all that came with it are gone.  Now, what if neither scenario happens?  For example, the user abruptly closes the browser.  NetTalk has no way of knowing this and the session can still be alive.  Have ever closed your browser and re-opened it fairly quickly and noticed that you were still logged in?  This is an example of the session still existing.  That's where that timer is important.

Does one overwrite the other?

No.

Could they be consuming memory if the app is not closed

The thread for the session consumes some memory so long as the thread is active.  But not much.  Most of the activity/memory use occurs when a GET or POST happens, but, again, it is not much and it is over and done pretty quick.

I'm running a NetTalk multi site host on a free tier level Amazon EC2 server with maybe 1 gig of RAM and one processor.  My NT server never misses a beat.  Runs 24/7 for months at a time.  The only time it goes down is when I have to update a DLL or the Host.

Fun stuff huh?

Don

[Bruce]

Hi Guys,

Ok, so there's a fair bit wrong with Don's answer, so I'd like to clarify some points there...

>> I tend to think to think of the Session ID as a GUID for the new thread created by a user logging in to the app.

SessionID's are separate to whether the user is logged in or not. They are created when the _site_ is first accessed by the user (logged in or not) and they only terminate after the timeout expires. (again, logged out or not.)

There are some security settings which can override this - but you won't go wrong understanding it as above. The main thing to know is that Sessions belong to the "browser", regardless of the loggedin / logged out status.

>> Have ever closed your browser and re-opened it fairly quickly and noticed that you were still logged in?

Sessions are stored in Memory cookies, so if you close your browser then the session ID is lost on the client side. (Bear in mind that "closing the browser" typically means closing "all" the browser, not just the tab, or window, to the site. So if I have 2 instances of firefox open, closing one does not mean "closing the browser".)

If you genuinely close the browser the session cookie is lost and your next connection will be on a new session.

>> The thread for the session consumes some memory so long as the thread is active.

This part of the answer links the session values to a thread. This is very much not the case. In fact it's the exact opposite. Sessions exist outside of threads - which is why they allow the app behavior to work, even though the app is constantly opening and closing threads. Sessions consume memory yes, but it's the exact same memory regardless of the number of threads. You can have 100 threads, or no threads, and the Ram consumed by the sessions is unaltered

Threads do consume their own memory - that's something different though and has nothing to do with sessions.


I'll answer Richards questions separately...

Bruce

[Bruce]

Hi Richard,

>> What happens to these variables?

>> Do they last as long as the app is open

no.

>> or as long as the browser is connected?

no

>> or until timeout?

until timeout. (time since the last activity from the browser.)

>> Does one overwrite the other?

A session value can be considered as having 3 parts;
a) the Session ID
b) the "name"
c) the "value".

There is only one value stored for a SessionID/Name combination. So a
p_web.SetSessionID(name,value) overwrites the exiting value for this session, for that name.

>> Could they be consuming memory if the app is not closed

In one sense yes, Session Values use up some ram. How much ram depends on the number of session values at any one time.
But in the sense you are asking, I think the answer is no. If the browser stops talking to the server, then the session will timeout, and all the session values for that session will be discarded.

The timeout value is up to you - default value is 15 minutes.

cheers
Bruce

[DonRidley]

Thank you for the clarification.  I forgot about the cookies.

You actually helped me identify an issue with my app.

My overall point is RAM use is not a major concern.

Don

[Richard I]

Many thanks Bruce,
As you may recall I have a NT "Turnstile" accepting residents entering a code for a meal.
The meal sitting is  2.5 hours, so I have made the timeout 2.5 hours, because at 15 minutes the  app was timing out due to inactivity either at the start of the sitting or at the end.
In your reply you suggest, I think, that all the sessionIDs are in memory on the server(?) until timeout, irrespective of whether the  remote browser is open or closed.

Can I force the deletion of the sessionID by using Notifydeletesession embed with the code self.deletesession

I am being challenged by a clients IT dept that the memory leak being experienced is due to my app
but from what you have said, am I safe in assuming that if the app is running idle on the server, it will timeout eventually, ( in my case after 2.5 hours) and delete all sessionIDs and release any memory they may have been holding?
Thank you
Regards,
Richard

[Bruce]

Hi Richard,

>> As you may recall I have a NT "Turnstile" accepting residents entering a code for a meal.

Alas I don't recall the details. Are they using a browser interface? From a single terminal as they enter? or from different terminals like their phones?

>> The meal sitting is  2.5 hours, so I have made the timeout 2.5 hours, because at 15 minutes the  app was timing out due to inactivity either at the start of the sitting or at the end.

This suggests a single terminal? Which suggests they're all sharing 1 session? and the users don't "log in" right, they just enter a code - like a PIN code or something to indicate "hey, I'm here, I'm having a meal".?

>> In your reply you suggest, I think, that all the sessionIDs are in memory on the server(?) until timeout, irrespective of whether the  remote browser is open or closed.

I feel like there is either only 1 session (they're all using 1 terminal) or there are lots and lots of sessions - but each user only uses their session for a few seconds at the start of the meal. Perhaps you can clarify this.

Either way the ram usage by the sessions will be minimal. I mean, like, hardly measurable.
Let's say you have 1000 students, and each session uses 5K (which in itself is grossly excessive) that would still only be 5 megs of ram.
If you have a memory leak, then I'd suggest it has nothing to do with the sessions....

>> Can I force the deletion of the sessionID by using Notifydeletesession embed with the code self.deletesession

no. You could delete sessions in another way, but you are going down the wrong rabbit hole here.

>> but from what you have said, am I safe in assuming that if the app is running idle on the server, it will timeout eventually, ( in my case after 2.5 hours)

in your case 2.5 hours _after_ the last person has eaten.

>> and delete all sessionIDs and release any memory they may have been holding?

yes.

>> I am being challenged by a clients IT dept that the memory leak being experienced is due to my app

It's easy to see if an app overall is leaking memory. TaskManager measures memory usage, and while it's not terribly helpful at the micro level, it's useful over long periods of time to see if the memory consumed by a program is going up. For example your program starts with likely only a few megs of ram used, then grows during a meal session by say a few more megs. But probably lives under 100Megs all the time. If however it keeps going up, with each meal service then it is leaking.

There are so many ways for a program to leak, but generally it'll be your code (not sessions.) Are you, for example, storing any information in memory tables? Or (heaven forbid) global queues?

And what file driver (TPS? ODBC? etc) are you using? And what build of Clarion are you on?

Bruce

[Richard I]

Thanks Bruce,
I have wasted enough of your time on this so Ill let it go, but to answer your questions:


There are 7 Dining rooms each with two terminals, all reporting to one app, via  browsers.
Yes, the students just enter a code and push ENTER
The initial session ID is created when the Administrator connects, and then its just left running.
There are no memory Tables or  memory Queues and only  TPS files used.
The Clarion version is PE 10.0.011834

I remain confused about your comment that:
'I feel like there is either only 1 session (they're all using 1 terminal) or there are lots and lots of sessions - but each user only uses their session for a few seconds at the start of the meal'

In the Log tab of the web server  there is new sessionID created for each student's  activity, which would mean there are  approx  2500 SessionID  over each meal sitting.

Im content if all these sessionIDs are cleared after the 2.5 idle time.

Cheers
Richard

[Bruce]

Hi Richard,

>> >> I feel like there is either only 1 session (they're all using 1 terminal) or there are lots and lots of sessions - but each user only uses their session for a few seconds at the start of the meal'

So actually something in between. You have a limited number of terminals (14) so at a max you have 14 sessions.
You can monitor the number of sessions, and the amount of session data on the "Performance" tab of your server, but frankly it's not the sessions that is using memory in your case. 14 sessions is nothing, I've seen servers with over 5000....

>> In the Log tab of the web server  there is new sessionID created for each student's activity, which would mean there are  approx  2500 SessionID  over each meal sitting.

this doesn't make a whole lot of sense to me. So tell me more about this;
like - where in the log tab are you seeing the extra sessions? in the incoming requests, as cookies?
and why are they all different? That's a little puzzling...

Do your students "log in" or do you just capture their student number?

Cheers
Bruce