As for “triggering” the interruptionMessage, that only occurs when the browser detects that the server isn’t responding when a message or ping is sent. The change that was made in r3 was to send a ping to the server at about half the SessionTimeout period to keep sessions from timing out. So if SessionTimeout is set to 180 (the default), at 90 seconds since the last activity, the browser attempts to send a message to the server as if to say “I’m still here, please don’t close my session”.
One problem is that when a browser or browser tab is sent to the background, JavaScript tends to run slower, being given smaller slices of time in which to run, so the timing of this Ping is a little unpredictable.
Ok, I’ve changed Nginx back to http 1.1 as you guys recommend (although it worked fine for so many months until I’ve uploaded the webapp compiled with the new r3…) .
I’ve added keepalive 64; under the upstream configuration of nginx (haven’t used that directive untill now)
I have reported the problem several times in the test channel in the pre-release phase of r3. Unfortunately everyone using the app compiled in r3 behind a proxy (in my case apache with http2 in a centos 7) has continuous disconnections. I’ve been searching for the problem for weeks with no results. Increasing the connection timeout of the proxy increases the lifetime of the sessions, but then they close unexpectedly. I’ve tried forcing the connection to http1.0 (SetEnv force-proxy-request-1.0 1) and disabling chunked (SetEnv proxy-sendcl 1 and SetEnv proxy-sendchunked 0 ) but it didn’t work. With r2.1 everything works correctly.
What version and environment are you using? We need to see how many people have already updated to r3 and if they have noticed the problem. You will see that slowly there will be more and more people reporting the problem. Already from the test phase until today the cases have increased…
At this point, I’m fairly certain 100% that this is caused by something that was changed with the release of the new version.
I’ve tried everything I could but nothing fixes the situation. Plus the coincidence is just to big to be ignored. Nothing changed on server side for months, nothing changed in the webapp code, just compiled with the new Xojo release 3 and the problems started instantly.
My advice for all the users that have important webapps, do not upload them built with release 3 if you’re running them behind apache/nginx proxy.
I experienced the exact same thing. Web app working perfectly on Linux behind nginx now has disconnections with no code changes when compiled with 2021r3.
If you really haven’t touched anything besides the extra ping is it possible to do some testing by removing this feature? I changed the value of DeflateBufferSize to prevent chunked messages and it seems to have improved. The problem has not gone away completely though.
Honestly, at this point, I’m in a state where I don’t want to make any other changes to the backend, because I know for a fact it shouldn’t be required or needed. Plus because my webapp is fairly big and this error happens only in production, everything I test has to be on a clients server and that interrupts the work of more than 20+ users logged in the webapp.
I have up and uploaded a version built with r2.1 and guess what… it works!
You are absolutely right and I understand that. I spent days testing and recreating the production environment to do the testing. It would be really helpful for everyone though. On apache modifying DeflateBufferSize seems to work (for now). I was curious if on nginx the problem is also solved.
In any case if someone already has a test environment with nginx that wants to do this test is welcome.
I will try during the night to re-upload the webapp compiled with xojo r3 and in the meantime I will also look at the equivalent of DeflateBufferSize on nginx.