cgi not responding properly

Hi!

As requested, a new thread here.

Alexandre

Ok, let me see if I can figure this out…

Hi!

Any news? Any clue?

Alex

As I’ve written in the other thread I’d have a look to TimeOut within the Apache Configuration (Or anything that is between the App and the net like a reverse proxy). From your server all the push requests get a error-reply after 40 sec. Other servers like the one from @Christian+Schmitz do send a HTTP 504 after 120s. I’ve seen other apps/servers responding gracefully (HTTP 200) after 180s. There is also a Feedback Case on the cgi Timeout Issue: <https://xojo.com/issue/49528>
I’m unsure, thus, if these TimeOuts on push long polling XHRs are the cause of your issues. But it seem worth to give it a try.

[quote=376558:@Tobias Bussmann]As I’ve written in the other thread I’d have a look to TimeOut within the Apache Configuration (Or anything that is between the App and the net like a reverse proxy). From your server all the push requests get a error-reply after 40 sec. Other servers like the one from @Christian+Schmitz do send a HTTP 504 after 120s. I’ve seen other apps/servers responding gracefully (HTTP 200) after 180s. There is also a Feedback Case on the cgi Timeout Issue: <https://xojo.com/issue/49528>
I’m unsure, thus, if these TimeOuts on push long polling XHRs are the cause of your issues. But it seem worth to give it a try.[/quote]

Hi!

But this can occur even USING the webapp?

Because using or not the problem is the same!

Alex

yes. I don’t know CGI. But with a standalone reverse proxy app under apache, it’s important. The Apache configuration is important.

I changed Apache timeout from 20 to 300 seconds. Same problem!

I tested again with Safari on the the URL you’ve posted in the other thread. Still the “push” requests do get a HTTP 504 Gateway Timeout answer after 40 sec.

Later I saw a “ping” request beeing unanswered because of a Connection Reset. This lead to the client side JS showing the “The application has gone off-line.” message and starting the offline-polling. That polling is apparently directing the wrong URL polling “http://alemac.com.br/cgi-bin/test/xojo/ping” instead of “http://alemac.com.br/cgi-bin/test/test.cgi/xojo/ping” which is, imho, a bug on its own affecting the CGI target: <https://xojo.com/issue/51525>. This is causing lots of (correct) 403 or 404 errors.

But still, your configuration change seems not to be active or at least not helping with the 504 messages. Nor do I understand why the connection of the “ping” call was reset.

You do have some logging in the App to confirm it is not crashing / the same instance is running continuously, don’t you?

[quote=377317:@Tobias Bussmann]Later I saw a “ping” request beeing unanswered because of a Connection Reset. This lead to the client side JS showing the “The application has gone off-line.” message and starting the offline-polling. That polling is apparently directing the wrong URL polling “http://alemac.com.br/cgi-bin/test/xojo/ping” instead of “http://alemac.com.br/cgi-bin/test/test.cgi/xojo/ping” which is, imho, a bug on its own affecting the CGI target: Feedback Case #51525. This is causing lots of (correct) 403 or 404 errors.

But still, your configuration change seems not to be active or at least not helping with the 504 messages. Nor do I understand why the connection of the “ping” call was reset.[/quote]

English, please…

No. In this case, it’s a simple cgi app. the app does nothing.

On Xojo Cloud, that’s perfectly legal.

Ok. That’s causing the cgi to not respond properly?

If i understood correctly, it’s a bug on xojo cgi itself, right?
If yes, any idea when it’ll be fixed?

Alex

I’m sorry if anything I said was not understandable, I’m not a native speaker.

The issue with the path for the reconnect ping (#51525) which seem to require a special webserver configuration (present at Xojo Cloud) is just a second thing preventing the automatic re-connect. I think it is negligible here.

I tested again with Chrome and Safari from Switzerland. The connection reset did not happen again, both browsers keep the connection just fine. But still the “push” POSTs receive a 504 after 40 seconds - which alone should not cause a disconnect. I’m out of ideas here.

Edit: I thought you said your server was on Xojo Cloud, but I see that it’s not.

I too am at a loss. We have hundreds of customer apps running on Xojo Cloud built with various versions of Xojo which are not encountering these issues, including a few of ours.

@Alexandre Cunha - no, it is not a bug in the cgi script. Every Xojo web app cgi script is identical. If something were wrong, they’d all be failing.

That’s not what I said. On Xojo Cloud, the servers are configured to allow the cgi script to behave as an index file so that they don’t have to appear in a he url… and since the trailing “xojo/ping” is virtual, it should work just fine. This configuration is not required for the feature to work.

The 504 Gateway error indicates that the app simply isn’t responding in the time that Apache thinks is long enough, about 40 seconds in this case, and yes, that is too long for a web app to take to respond. Humans get frustrated at 3 seconds, 40 is an eternity.

App crashes are usually the culprit, but if the app isn’t crashing, the second most likely scenario is that the app is hung because it’s waiting for something. If your app connects to another service or server, make sure those are “always” available, that the appropriate firewall ports are open and if something unexpected happens that your app doesn’t crash if it gets no result (like an empty result from an HTTPSocket when you are expecting json).

The next most common issue is that your app has a method that takes a lot of cpu for an extended period of time, effectively locking out the browsers until it’s finished. This usually occurs because of an unyielding tight loop in your code. A common example is retrieving a large recordset and sending all those rows to a listbox at once. It’s a double whammy actually because you pull the records in a loop and then all that data has to be sent to the browser.

Ok, so I’ve jut gone to http://alemac.com.br/cgi-bin/test/test.cgi and your app is definitely taking too long to respond. looking at the debug tools, I’m seeing latencies between 4 and 7 seconds to return the built in pictures which are all below 10 kilobytes, heck, the Shown event on the page is taking 6 seconds to respond and the response is actually empty.

There’s are a few possibilities:

  1. The server is really busy and the app is not getting enough time to respond.
  2. The app is really busy (as in my previous post, but that doesn’t seem likely given the url I’m using)
  3. The server is throttling or killing the app (which I’m beginning to think is the most likely scenario)

Lets get some specifics about your server as I see that you are not on Xojo Cloud.

  1. Is this a private or shared server? That is, are you paying for a full Virtual Private Server or is this simply a hosting account?
  2. What is the OS & Version your server is using? cat /etc/os-release should get that for us.
  3. How many CPU cores do you have and how much memory is available? If you have shell access, running the command “top” will give us this info.

@Alexandre Cunha - On that sample app, please download the following file:

https://www.dropbox.com/s/h8wwc2lyh9vlcsa/ServerPingFix.xojo_binary_code?dl=1

drop that file into the project and then drag an instance to WebPage1 (or whatever page is shown there). This may not solve the overall problem, but may help with the ping problem.

i’ll check

i think it’s not, as you could see on sample app

i need to check.

https://www.knownhost.com/managed-ssd-vps.html
mine is a MVPS-3

NAME=“CentOS Linux”
VERSION=“7 (Core)”
ID=“centos”
ID_LIKE=“rhel fedora”
VERSION_ID=“7”
PRETTY_NAME=“CentOS Linux 7 (Core)”
ANSI_COLOR=“0;31”
CPE_NAME=“cpe:/o:centos:centos:7”
HOME_URL=“https://www.centos.org/
BUG_REPORT_URL=“https://bugs.centos.org/

CENTOS_MANTISBT_PROJECT=“CentOS-7”
CENTOS_MANTISBT_PROJECT_VERSION=“7”
REDHAT_SUPPORT_PRODUCT=“centos”
REDHAT_SUPPORT_PRODUCT_VERSION=“7”

[quote=377486:@Greg O’Lone]
How many CPU cores do you have and how much memory is available? If you have shell access, running the command “top” will give us this info.[/quote]
4 cores, 6GB

top - 09:37:22 up 7 days, 18:21, 1 user, load average: 0.59, 24.33, 122.19 Tasks: 80 total, 1 running, 77 sleeping, 1 stopped, 1 zombie %Cpu(s): 21.3 us, 3.7 sy, 0.0 ni, 75.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 6291456 total, 2433172 free, 2209344 used, 1648940 buff/cache KiB Swap: 0 total, 0 free, 0 used. 3919776 avail Mem

[quote=377487:@Greg O’Lone]@Alexandre Cunha - On that sample app, please download the following file:

https://www.dropbox.com/s/h8wwc2lyh9vlcsa/ServerPingFix.xojo_binary_code?dl=1

drop that file into the project and then drag an instance to WebPage1 (or whatever page is shown there). This may not solve the overall problem, but may help with the ping problem.[/quote]

Done!

new_instance

Jason, from xojo’s support, uploaded my previous cgi to xojo cloud.
as expected, worked fine!

http://67.205.169.107/test-Dev/

so the problem is a configuration on my server. i just need to know which configuration is!

the strange is that only occurs on MAC clients, not WINDOWS

Alex

[quote=377492:@Alexandre Cunha]Done!

new_instance[/quote]
Ok, did you upload that app to your server?

Yes, but i’m sorry, did not kill the actual cgi.

You can try now.