Thanks so much for your interest in this bug, Matthias! I'm just getting
back into it now, catching up on bug comments posted since yesterday.
Phil
On 5/8/20 5:28 AM, matthias rebbe via use-livecode wrote:
Phil,
i´ve answered already to the bug report, but maybe this is also of interest for
the others.
As i have also accoun ton the same On-Revi as you and did some test.
I am sure it´s a tsNet timeout problem.
tsNET has several default timeouts. The defaults are 30, 0, 300000, 60000, 30,
1000
The fifth one defines "the time period in seconds that is used to calculate
whether or not the transfer has fallen below the low speed limit set by
pLowSpeedLimit."
It can be set either to 0 to disable the time out or to any other value.
In my first test my LC Server script returned just a 5MB file back to the
client. That worked.
I then added a "wait 45 seconds" to the script before outputting/returning 5MB
file to the client. I got exactly the same error message than youor your clients,
"tsneterr: (28) Operation too slow. Less than 1000 bytes/sec transferred the last 30
seconds"
This makes sense as because of the "wait 45 seconds" we exceeded the default
time-out value of 30.
I then added the following line to the client script.
tsNetSetTimeouts 30, 0, 300000, 60000, 120, 1000
With it i´ve changed the timeout to 120 seconds.
After adding that line, the 5 MB file was received again by the client w/o the
tsNet error.
So setting the timeout either to a higher value or to 0 in the client script
should solve it. I am not sure, but i assume setting it to 0 is not recommended.
Hope this helps.
Matthias
-
Matthias Rebbe
Life Is Too Short For Boring Code
Am 07.05.2020 um 20:35 schrieb Phil Davis via use-livecode
<use-livecode@lists.runrev.com>:
Thank you all for so many great questions and responses! I don't have time to
give a comprehensive response right now but (1) I'll whittle away at it and (2)
all your comments renew my hope that a solution is out there waiting for me to
find it.
Quick responses:
- I too would start by going back to LC 6.6.x on the server if I could, but
apparently the recent server upgrades - new hardware running LC 9.5.1 - are not
backward compatible. That's what I'm told at least.
- The LC client app is POSTing a request to an LC CGI system on an on-rev server.
The server system assembles a data packet (normally an encoded array), encrypts
& encodes it and writes it back to the client. The packet can be any size up to
maybe a megabyte or two, but that would be pretty big. Normally the packet size is
no more than a few hundred KB.
Thanks again -
Phil
On 5/7/20 7:29 AM, Ralph DiMola via use-livecode wrote:
Phil,
I had a problem with a GET request with a url encoded url in a parameter
after the upgrade. There are new security rules. I changed it to a POST and
it then worked. I am changing my apps to use a POST. Robin had lifted the
new security rule for me temporarily until all the apps are updated. One
other thing, the new MySQL server is now Maria DB. It is functionally the
same but I noticed if you have a column with no default value but is
required and the field is not in the SQL update then it throws an error.
MySQL did not do this.
Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net
-----Original Message-----
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Phil Davis via use-livecode
Sent: Thursday, May 07, 2020 3:18 AM
To: How to use LiveCode
Cc: Phil Davis
Subject: on-rev server upgrade-related problems
Has anyone had part or all of an on-rev server-based system stop working
since the server upgrades a month or so ago?
My client has an on-rev.com-based training system. Training delivery is via
web browser, and that part continues to work. But there are several desktop
apps that provide training development, management and real-time monitoring.
All of those apps became non-functional as soon as the upgrades were done,
and remain so. I haven't been able to figure out how to restore
functionality.
Robin in on-rev support has been very helpful, but we still don't have a
solution. This is the bug report:
https://quality.livecode.com/show_bug.cgi?id=22704
I wouldn't wish this on anyone, but in a way I'm hoping it isn't just us.
Thanks -
Phil Davis
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
Phil Davis
503-307-4363
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
Phil Davis
503-307-4363
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
