Session Interrupt Message

for no apparent reason, sometimes it is displayed the session “Interrupt Message” (We are having trouble communicating with the server. Please wait a moment while we attempt to reconnect).

after the message, the reconnection almost never happens and it is not clear if the current process is finished correctly.

is there any way to handle this issue?

if not, is it possible that the “Interrupt Message” doesn’t fire, forcing instead the session to close?

There has been much discussion (and some workarounds) for this. You did search the forum ?

before creating this topic I searched, but didn’t find.
probably my mistake.
can you point me to something?
thank you

Here’s mine for automatically reconnecting after a set period of time. Read further down for another version to handle other issues:


Anthony’s method works quite well. Unfortunately, Xojo in all their infinite wisdom did not see fit to add the same reconnect capability to Web2 as the original web version. Web API1 is so far superior in this sense. They really got it right in the latter versions of Web1. Works really well. I am still befuddled as to why this didn’t carry over to Web2.

1 Like

in all my tests, the session is not maintained.
after the timeout a new session is started.
this is certainly a much better condition.
I absolutely didn’t know what to do.
thanks Anthony!
but what happens before the timeout?
is the session already dead or does the current processing continue until the end?
I think Xojo staff should clarify.

1 Like

AFAIK it isn’t really a reconnection, but a restart, with new connection. So your session will be discarded, not reconnected. It can cause issues if you count with a session.

The reason we don’t do this by default is all about traffic.

Since the primary reasons for a web app to be non-responsive are that the app crashed or that the app is too busy to respond (like a tight loop) having all of the sessions pinging to see if the server is still there just increases the load on the app during a time when it is having trouble responding anyway.

The system works in Web 2 is that if the client detects that the server isn’t responding, it shows the “hold on” dialog to get the user to stop interacting with the app. This is done in the hope that you don’t lose too much state info. The browser sends several pings to the server to see if it’s coming back and if it doesn’t, the user is shown the disconnect message and the pings stop.

Greg, the automatic reconnect in web 1 was so much better.

Please think outside the box. Not all of us use web apps to drive traditional web pages on the internet. We use them all sorts of places where having automatic reload is really needed.

For example, I have a web app I wrote in 2.0 that presents a schedule that is loaded by a digital signage player. The web app runs on a Mac that may need to be rebooted, etc. If the Mac reboots, the web app is started in boot but the signage player never knows to reconnect. I have to force the signage player to reload the web page every few minutes so this doesn’t happen. Talk about unnecessary traffic and actions.

Your inside the box thinking of web apps and how they are used is really disturbing. The beauty of Xojo Web is that it should be easy to write a quick web page for LAN use only as is my case here. Not everything runs on a server with high load.

You’d be surprised how many non-traditional uses there are. It Xojo Web 2.0 is not easy to use and it appears designed to try to compete with traditional web sites. Sad.


Or let’s use my main web app in 1.0 which is a remote control for a video system. If I take my phone outside the network where the video system is run, I lose the page and rightly so. But as soon as I bring my phone back on the LAN with the video system, and bring the page up, boom! It reloads. Like magic.

Not lots of server traffic. LAN based running on a Mac or Windows PC not some cloud server.

Give us the choice at least.

1 Like

Have to agree with Jon on this one. I’m I guess fairly non traditional too. I am on a closed network. with an iPad talking to a server. One peer only.

“The system works in Web 2 is that if the client detects that the server isn’t responding, it shows the “hold on” dialog to get the user to stop interacting with the app.”

Greg, I don’t see this behaviour at all. My system has quite a lot going on both client and server side, but if I bring the server down then my app doesn’t ever show the ‘reconnecting’ dialog. It just sits there forever unresponsive. Not a great user experience.
If I pull the network then I do see this, but I can quit the server app or turn off the server without a disconnect warning.

Agreed. I’ve not seen this with my Web 2.0 app either. Just nothing.

@Greg_O_Lone I agree with @Jon_Ogden or I suppose the vast majority (if it were a survey), today the closest solution is that of @Anthony_G_Cyphers that I am using, otherwise nobody finds out that it is disconnected.
No matter how good a good application is created, we know that there are “changes” on the mobile phone, it simply “exits” the browser and that already causes the “crash”. I wonder they just don’t prove that IT IS NOT FUNCTIONAL.

But I am 100% Web 2.0 incha

Pero soy “incha” (no se como traducirlo) 100% de Web 2.0
(quizás @AlbertoD me ayude con la traducción jaja!)

@Mauricio_Tanco you can translate that as a super fan/supporter.

1 Like



Hello everybody, I can only agree with Jon. Using a private server, mostly access it through the mobile phones which means that connections are lost quite often. Web1.0 was handling this very well. As Jon pointed out in a subsequent post, please give us the choice at least. I understand the traffic concern, but this is not applicable to all situations.


@Greg_O_Lone ALL my web apps are on a LAN and not on the internet. I am 100% in agreement that we should be given the choice to have app reconnection like in Web 1.0. A simple reconnection type checkbox in the Build Settings Shared to enable Web 1.0 connection behavior would be desirable. I’m not sure what you should actually call that setting but I definitely want that behavior back.

1 Like

We have the same, 80% web apps are on lan not on the internet and keep the connection as long as possible is ok. but if one leaves (close the tab or browser) the session may close (i dont see an issue with that). Aut refreshing on resume from lost connection, and therefor creating a new session is ok.