[quote=436433:@Greg O’Lone]Lets tackle these one at a time.
Event.TimedOut means that you have set Session.Timeout to some number other than zero. It would be helpful to know what that is.[/quote]
Ok. Well, Session.Timeout will be either 30 or 900, depending on whether their Session was at the LoginPage and they never bothered to log in (Timeout is 30 seconds), or they logged in and are in what we can call the MainPage, where they can now enter some data if they want (Timeout is 15 minutes).
The Session.TimedOut code is simple:
Self.Quit
Looking at the access.log, the last event from that IP Address was about 36 hours prior. Here’s the prior non-500 event, followed by the 500 event I posted above, with all intervening events from other IP Addresses removed (GMT timezone) and irrelevant data removed:
[quote][13/May/2019:03:50:18 +0000] . . . GET . . . /comm/serverevent HTTP/1.1" 200 10
[14/May/2019:16:02:40 +0000] . . . POST . . . /comm/event/Event.TimedOut HTTP/1.1" 500 649[/quote]
I don’t usually see that TimedOut event in a 500 log entry. That just happened to be the last one, and it was all by itself, without any 500 events preceding or following it. When I see a 500 event, I usually see something like
But it can be just about anything.
And these 500 events are not immediately preceded by other events by the same IP Address, unless those immediately preceding events are also 500 events from the same IP Address. So such an event (or series of a few such events from the same IP Address) seems to always arise when the user simply hits the app. And they are always associated with those Line 118 errors in the CGI file that many have reported, so I assume it’s always when the user hits the app when it’s not running.
I’m assuming this all has to do with the mobile Javascript problem you mentioned before.
Edit:
And, BTW, dropping the LoginPage timeout to 30 seconds is fairly new. Users were previously always timed out at 15 minutes before, and I was getting the same behavior then.