Session / Server comms - life cycle

Hi All,
I have an App running with 42 user ( clients ) sessions open all day every day. I’m experiencing drop offs
where clients loose their session and have to restart the app on their iPads, and am trying to get to the bottom
of what’s happening.

I’m logging each session open and close and comparing this to the server logs using session ID and the logs correspond
exactly. I too have one of these iPads sitting on our shop counter so I’m part of the experiment.

I see the session is talking to the app about every 3 seconds. How many seconds must be missed ( maybe due to lost connection )
before the server decides to discard the session ? How many more seconds before the user must actually restart their
web app ? Is this how it works ?

Today, my log showed my iPad close and open new sessions intermittently for no apparent reason. Opening new
sessions then closing the original one three mins later. Use of the App was un interrupted i.e. no lost connection, so why did
it close existing sessions and hand out a new one immediately to carry on with.

Is anyone able to shed light on this. Bit of a curly one I know.


Mobile devices are kinda special these days. In an attempt to save battery power, they’ll sometimes throttle or pause the JavaScript engine in the browser to save CPU cycles.

By default, a browser must be gone for three minutes before the server destroys the session… and that corresponds to what you are seeing except that it only happens after a new session starts. That seems to indicate that the old session is actually still alive in some way.

One other possibility though… is the IP address of the iPad’s connection changing? If the server is off-site, that would be your location’s public IP, if it’s local, it would be the iPad’s IP itself.

I guess another possibility is that you have a long running process that is using so much CPU that the app can’t respond to browser ping requests.

It would be helpful to know what version of Xojo you are using because we have updated the communication protocol from time to time. Also, which platform is the server running on?

Hi Greg,

The App is on Xojo Cloud ( but a Sydney server ).
I’m using 2018r1
Each store has a static IP address and the iPads are only connected to the correct wifi SSID. If the wrong IP is detected by the App it tells the user and responds accordingly.

I don’t have any ongoing processes that I know of. I haven’t seen any evidence of this in XCtop but will keep an eye on it. It usually sits around 5% to 8% CPU and about 100000 free memory. I am getting a lot of index.cgi though, is this normal ? I’ve never seen them before.

But what I’m seeing in the server logs is a ping every three seconds right up until it’s gone and immediately following is the start of a new session. Why would a new session be started even though the old one is still pinging ?

Thanks for your help.

That’s normal. Each connection that a browser makes to the server results in an instance of index.cgi. The defunct indicator usually means that it’s been abandoned by the client or the server, but not entirely an indicator of a problem.

Excellent. 2018r1 has both the built in stats (instead of using XCTop) and the newer eventSource communication module for iOS which takes the device’s power needs into account.

Now that I know what version, I can talk about pings :slight_smile:

The Ping mechanism kicks in when the browser thinks the server has gone away and is actually waiting for a response. My suspicion is that those responses are not getting through for some reason, but we’ll have to look at your server to confirm that. I’ll do that today, but I may have tech support contact you if we need any more information.