2021 R3.1 - Lost Connection Behavior Different?

I’ve put my Web2 app built with 2021 R3.1 in production, and there’s something different about how lost connectons are handled. I’m not yet sure of the steps to recereate it, but I think it happens when your browser tab is no longer frontmost (or maybe when your computer sleeps?) The end result is that the web app looks normal, but nothing works.

In earlier versions, you would always get the “Lost Connection” message, but that seems more hit or miss in 3.1.

Anyone else seeing similar?

Easy to reproduce in debug:

  • Xojo2021R3, when I stop debug I always get a problem connecting or lost connection message after a few seconds
  • Xojo2021R3.1, when I stop debug I don’t get the message even after several minutes

I think someone reported a disconnection between 4 and 5 seconds of no activity without any message and the page looks like is active but nothing works. Maybe there is a Feedback about that (don’t remember right now).

Edit: Eddies with Xojo2021R3.1 debug stopped (after 2 minutes)

Eddites with Xojo2021R3 debug stopped (after 10 seconds)

1 Like

Where’s the web app running? Xojo Could? Linux box? Locally-OS? What browser are you using? Have had user’s have issues using a few web apps in Mozilla.

I use Linux servers for all my web apps, & did have to recompile from r3 to 3.1, to get the disconnection issue fixed, that pervaded the previously release. So far no unresponsive apps. When your app goes unresponsive, how’s the CPU look? - I Haven’t had the issue with API2.0, but in 1.0, if my app was really CPU intensive, even just for a moment, sometimes we could get the WebApps to “disconnect” from the Xojo backend and freeze-up without showing any “app disconnected” issue.

**No WebApps issues so far with 3.1 on debian Linux in my case.

Yup, I’ve noticed that also. It started happening after the entire https://forum.xojo.com/t/2021r3-how-do-i-debug-whats-triggering-websession-interruptionmessage/66925 debacle. But it’s not a game-breaker for me :slight_smile:

Doesn’t matter where it’s running. Just stop it (if in debugger) and you won’t see the disconnected message. At least that’s how I’ve noticed it.

@AlbertoD since you have the screenshots, would you be willing to submit a Feedback case (if there isn’t already one?)

Hi Mike - lol so we started a new web application today - and are just about done with a majority of the code… (it’s a video streaming service) - and low-and-behold, after a video plays for a few minutes - the app is completely unresponsive - minus the video still playing :slight_smile:

Looking in the Safari console/debugger, it appears the browser realizes it has lost connection, as there are error messages each second:

but these never seem to trigger the “lost connection” message. Curious!

1 Like

Yes! That’s it!! :slight_smile: Seeing the same type of output all related to comm/serverevent URL. Oddly - we haven’t had any issues in other apps. The only difference between other apps and this one is that we’re loading images for TV/Streaming networks from external URL vs internal/local ones. The services need to be in control of the images on their end…so hosting locally is not an option. Are you loading any external resources in your projects by chance?

Nope, and like @Gabriel_L I can reproduce this with a “Hello World” web 2 app with a single button just by stopping the debugger, so I think it’s definitely a bug in Xojo 2021 3.1.

1 Like

I found the relevant javascript and addedd my comments:

In 2021 R2.1:

// note: this triggers on XHR error
// eventsourceMessageCount starts at 5
// when it reaches 0, it calls preventInteraction() which pops up the lost connection dialog
eventSourceSocket.onerror = function(e) {
           --eventsourceMessageCount < 1 && preventInteraction()

In 2021 R3.1:

// note: this triggers on XHR error
// eventsourceMessageCount starts at 5
// however, it seems that eventsourceMessageCount  is never decemented.
// because eventSourceSocket.readyState does not equal  EventSource.CLOSED perhaps?

eventSourceSocket.onerror = function(e) {
  eventSourceSocket.readyState == EventSource.CLOSED && 
   --eventsourceMessageCount < 1 && preventInteraction()

The documentation for EventSource EventSource - Web APIs | MDN is not super clear, but I could imagine that readyState is never CLOSED inside the onerror handler, which may be leading to this bug?

I’m also having the same issue. Only in 2021 r3.1, the previous version was fine

I think it refers to my feedback but I’m not sure.
<https://xojo.com/issue/67089>

I submitted a new case to be sure:
<https://xojo.com/issue/67502>

2 Likes

I’m also seeing what I think is a related issue - I have an administrator view which shows me statistics on Active and Termiated sessions. In the old version, terminated sessions cleaned themselves up after a minute or two.

In 2021 R3.1, they seem to stick around - in this screenshot, every session noted with (X) is one that has been terminated, but still exists:

These “ghost” sessions don’t seem to be causing a big issue, but I imagine they are leaking a little bit of memory (and my app has only been running for about 24 hours - longer term, this would concern me)

1 Like

Here is a super ugly hack which seems to fix the bug.

Run this code in the session.Opening() event:

Session.Opening

dim js() as string = Array( _
"console.warn('###  JSStartAjaxConnection Hack Installed ###');",_
"/* window.alert('###  JSStartAjaxConnection Hack Installed ###'); */ ",_
"var comm = session.comm; ",_
"comm.Hack = ",_
"  function() {",_
"    console.warn('### Replacing eventSourceSocket.onerror function ###');",_
"    eventSourceSocket.onerror = function(e) {",_
"      console.warn('### eventsourceMessageCount = ' + eventsourceMessageCount ); ",_
"      --eventsourceMessageCount < 1 && preventInteraction()",_
"    }",_
"  }",_
"comm.Hack(); /* install the hack */ "_
)

dim jstext as string = String.FromArray(js,EndOfLine.Windows)
self.ExecuteJavascript(jstext)

How this works:

  • the session.comm object has an eventSourceSocket, which has an onerror handler which has a bug in it
  • because the session.comm.eventSourceSocket is a “let” variable, we can’t simply replace it from outside the object (e.g. session.comm.eventSourceSocket is not visible from outside the scope)
  • instead, we add a function to session.comm called Hack()
  • since Hack() is within the comm scope, it can see the session.comm.eventSourceSocket variable, and replace the onerror handler with the non-buggy one from Xojo 2021R2.1

Use at your own risk of course!

Here’s what I now see in the console when running this:

7 Likes

This workaround seems to also have fixed the problem with “ghost” sessions sticking around.

I’ve been using it for severl hours now, and all sessions seem to be cleaning themselves up properly.

3 Likes

Now hope that Xojo will add this fix ASAP to Web so we can have a STABLE web for once.

1 Like

Seriously Xojo please do a blog article or update the documentation to explain all the options related to timeouts, reconnections etc - I’m now totally confused as would appear to be the case for many about how these timeouts actually work.

Do reconnections even work?

1 Like

This Bug is at #60 at the moment.

Lets vote this on up!

https://xojo.com/issue/67502

1 Like