Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Chrome confused with session timeout/restart
Hi there.  I am getting a weird issue reported from users when a session times out.  In Firefox, all is well and the session is seen as expired and a new one started and my login screen is presented to the user instantly.  When the same issue occurs in the Chrome browser, this process is taking around 11 seconds to figure itself out.  When I am watching the activity around 2/3 of the time is figuring out the session is expired and then the rest of the time is waiting for the login screen for the new session.

I thought at first I had the server controller settings wrong or something but then only seems to be an issue in Chrome.  Is there something special I need to do to get Chrome to behave?

Here are the only 2 session values I changed from default.  I am using 15.1.12.  Cookies are just default.

SessionOptions.UniqueURL = True
SessionOptions.SessionTimeout = 300

Hi Bob.
I use this demo:
See in ServerController.pas (class function TIWExceptionRendererEx)
Thank you Jose.  I have that in my server Controller already.  

I wonder what is different in Chrome than other browsers for it taking so long.  I see the RestartExpiredSessions property and OnSessionRestarted event so a backup plan is to allow a session restart and then terminate the application so then this is hopefully kicked for Chrome but this sounds a bit clunky.  

Would be nice if Chrome would could be made to behave. Maybe it no longer likes that HTML in the TIWExceptionRendererEx.RenderHTML function.  

here are the things i would check :
* does it happen in every chrome or only on some machines? - version differences?
* write something to a log file just before every step before and after session closes
* if it happens only in SOME of your customers machines, then maybe they have some plugin that is driving your app crazy.
* if blaming everything else doesn't work - check your code for a bug... Smile

if it happens also in your dev machine :
* assume it's a bug in your code...
* in the browser - press F12 to look at the page's info.
you can look in the "Console", "Network" and "Performance" to see if there are errors and things that takes too much time to happen.
you can refresh the page to see the information changes and updated.

- to make it easier, you can set the SessionTimeout to only 1 minute, and then see the information changes in the browser when the F12 "panel" is already opned
I suggest that you try another machine (and, if testing remotely, preferably another network).

I tested the exact same demo that JNP mentioned above and it is instantaneous.

If you open Chrome's dev tools (F12) and whatch the network calls and put a breakpoint in your application (e.g. OnBeforeDispatch) you can find out where the 11 seconds are being spent (in chrome, in the middle or in your applicaiton)
Thank you all for your responses.  The machine seems to have no bearing on the issue since this was an external network that reported and I was able to recreate locally.  I know chrome is the latest version (80.0.3987.132) on my machine but unknown on client.

More information here is that when the session value timeout is low, then all is fine.  As I increased the number, then the time to establish starts to increase.  The local disk seems to just go wild and then there is a flash of a red and then the login appeared.  I happened to go to a machine that was sitting since yesterday and it took minutes to get things going.  So for the first phase nothing is occurring at all and the browser is just spinning.  Then it finally figures out that the session is gone and then the server tries to issue a new session.  This was that flash of red that I saw before but on this machine I was able to go deeper since the red was on the network monitor window for a long time.  When I zoom in on it, it says that the connect is stalled.

The status is 500 and the document is $/js/IWBase__376527852.js.  I have attached the js here so you can have a look at it.  The IW log on the server just says Session ID is invalid which makes sense.

Looks like the attachment never uploaded so I edited this to just add with an image screen shot as of this morning.  So the issue seems to really rear its head when I leave things overnight.  The browser said this morning that it was waiting on the web site instead of just spinning.  Is there something overnight that goes to sleep and takes a while to respond for an old session?  Seems to be nothing to do with my code.  No matter the server operation or page, the stall can occur.  All works fine in Firefox overnight though which is the perplexing thing.  


Attached Files Thumbnail(s)

.txt   DocumentStalled.txt (Size: 114.4 KB / Downloads: 2)
Hi there.  More information for you Alexandre.  The issue in the architecture when an expired session is attempted to be touched is really seen when the machine is left overnight and then that system just hangs in the old session ID with that document information I already sent.  I got rid of the lag for the new session creation by setting the RestartExpiredSession Flag to true and then putting session FreeInstance/create code in the the OnSessionRestarted event.  If I set only the RestartExpiredSession flag then I was seeing the same issue.

Hopefully this assists you to trace the issue in the architecture.  I am able to get into the session restart process so at least I eliminated that issue.  So to summarize, when the session is expired and machine left overnight, then when any server function is touched, the system hangs waiting.  The issue is in Opera now too but at least Firefox still seems OK.  Maybe this is a canary to a larger issue that more and more people will find as the whatever is different in the browser is seen more and more?

If I find anything else that I can add to this issue, I will let you know but I have hit a wall on what I can do from here on the first part since ANY server operation just hangs waiting for the session so nothing I can do.  The issue is also dependent on what is in the session too on length of time.  If I time out the session before I log into the system, then the time to get a new session is less time.  The key factors in my experiments are length of time the machine is left alone and size of the session.

Hi there.  Last thing I can post on here to hopefully trace the Chrome issue originally reported.  

By setting the RestartExpiredSessions property and OnSessionRestarted event I was able to decrease the dead session restart by 30%.  So now when the base system gets around to figuring out that the session code is invalid and completes all its work it is doing, then I get my new session start quickly and no longer a wait for the second part of my original issue.  Unfortunately I have no access to anything else in the first part since IW takes over as soon as there is any event clicked.

I even tried to start a batch job in the middle of the night to restart the IW service but this does not work either to speed things up.  If the user leaves their browser open over night just hangs for the first operation in the morning while it is trying to figure out that the old session code is expired.  If I let the session expire and then wait another couple of hours, there is a slow down while restart but not as bad as waiting until next day.  The longer the browser is open with an expired session the longer the IW application seems to take to figure itself out.


Forum Jump:

Users browsing this thread: 1 Guest(s)