Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008836opensim[REGION] Script Functionspublic2020-12-18 00:422020-12-19 13:05
ReporterKayaker Magic 
Assigned To 
PlatformDell T1400 server towerOperating SystemUbuntuOperating System Version16.04
Product Version 
Target VersionFixed in Version 
Summary0008836: llHTTPRequest has delay based on what is called next
DescriptionThere is typically a short delay for a round trip from llHTTPRequest to the http_response. I usually see 0.2 seconds. However, if I call llLoadURL soon after calling llHTTPRequest, the round trip time changes to a number suspiciously close to 10.000000. Sometimes the http_response is never called, but I cannot get that to repeat. However, I have a script that gets the time to go to 10.001000 every single time. It looks to me as if llLoadURL is changing some data structure that llHTTPRequest depends on.
The problem happens with a recently built version of 0.9.2 Yeti
The problem happens on Kitely as well, so it may have existed in 0.9.1 or before.
Steps To ReproduceStick the following script in a prim. Click on the prim. Ignore the llLoadURL dialog, just watch how long it takes for the HTTP request. Be patient, 10 seconds is almost FOREVER.

Then comment out the llLoadURL call and try it again. The round trip time becomes much shorter.
Additional Information//demonstrate the strange HTTP Request delay.
//put this in a prim
//click on it, note that it takes 0000006:0000010 seconds to respond
//comment out the llLoadURL call and try again
//the time drops to the expected time of 0.2

    llHTTPRequest("", [^]
        llSay(0, "Script running");
    touch_start(integer num)
        llOwnerSay("HTTP request started");
        llLoadURL(llGetOwner(),"Don't click on this, just watch the times","");
    http_response(key request_id, integer status, list metadata, string body)
        llOwnerSay((string)status+" time: "+(string)llGetTime()+"\n"+body);
TagsNo tags attached.
Git Revision or version number73d33aee3235953d91b10ff6e5a571e8c16f5b66
Run Mode Grid (1 Region per Sim)
Physics EngineubODE
Script EngineYEngine
EnvironmentMono / Linux64
Mono Version6.x
Attached Files

- Relationships

-  Notes
djphil (reporter)
2020-12-18 00:49
edited on: 2020-12-18 00:54

Yes, llLoadURL is a real horror, it makes the script sleep 10 seconds.
(More info @ [^])
To work around this problem, when I want to use it, usually I put it in a separate little script ...

osLoadURL would be very welcome here ...

UbitUmarov (administrator)
2020-12-18 04:10
edited on: 2020-12-18 04:14

yes having a script going to web is a real horror
in this case asking users do do so also maybe also, so the 10s

UbitUmarov (administrator)
2020-12-18 05:00

why are you doing llHTTPRequest and then llLoadURL when you do nothing with the response on the script?
llLoadURL is basically a invite for a user to load the site with its browser, unrelated to llHTTPRequest

made code changes to llLoadURL:
-silent fails on group owned prims
-url must be valid ( and start with http(s)://
-reduced script sleep to 1 second
CasperWarden (reporter)
2020-12-18 05:02

Lol, did someone implement a 10 second delay in opensim based on that info?

It's wrong, the delay in SL for that function is 0.1s
djphil (reporter)
2020-12-18 05:11
edited on: 2020-12-18 06:36

You're right, the SL wiki is not very up to date on this.
The delay page says 10 sec, the function page (en) says 0.1 sec and the function page (fr) says 10 sec, it's very confusing ...
I just tested in SL and it's 0.1 sec, I confirm it.

Edit: I have create a new mantis about it. [^]

Kayaker Magic (reporter)
2020-12-18 11:00

Ubit asked: Why call llLoadURL immediately after llHTTPRequest? Well, I don't always do this, but that combination caused a delay I did not expect. I think of llHTTPRequest as being asynchronous: I can make the request and let it happen in the background while I do other things, like tell the user to go load up a WEB page. I don't expect what happens in the foreground to have any effect on those asynchronous background tasks.
UbitUmarov (administrator)
2020-12-18 11:03

ok guess there are uses.. not this example :)
sl does list the delay as 10s like DJ did point out, possible it was in past
Kayaker Magic (reporter)
2020-12-19 12:46

OK, I should have submitted a mantis for llLoadURL. Why does it slow OTHER THINGS down? I suppose it has limits and delays, but why would that effect other functions that do not have those limits and delays? I always tell the viewer to use my external browser, so all llLoadURL has to do is send a URL string to my browser. That should use NO server resources and NO viewer resources. I suppose if I was still using the viewer internal browser it might bog down the viewer and it has issues. But again, all the server needs to do is send the URL string to the viewer. So how can this possibly have such a huge effect on other server functions?
UbitUmarov (administrator)
2020-12-19 13:05

it is not effect on server, it is on that script execution only
The forced delays are not only about protect server resources, are also abotu preventing viewers spam, etc

- Issue History
Date Modified Username Field Change
2020-12-18 00:42 Kayaker Magic New Issue
2020-12-18 00:49 djphil Note Added: 0037393
2020-12-18 00:54 djphil Note Edited: 0037393 View Revisions
2020-12-18 00:54 djphil Note Edited: 0037393 View Revisions
2020-12-18 04:10 UbitUmarov Note Added: 0037398
2020-12-18 04:14 UbitUmarov Note Edited: 0037398 View Revisions
2020-12-18 05:00 UbitUmarov Note Added: 0037399
2020-12-18 05:02 CasperWarden Note Added: 0037400
2020-12-18 05:11 djphil Note Added: 0037401
2020-12-18 05:24 djphil Note Edited: 0037401 View Revisions
2020-12-18 06:36 djphil Note Edited: 0037401 View Revisions
2020-12-18 06:36 djphil Note Edited: 0037401 View Revisions
2020-12-18 11:00 Kayaker Magic Note Added: 0037403
2020-12-18 11:03 UbitUmarov Note Added: 0037404
2020-12-19 12:46 Kayaker Magic Note Added: 0037405
2020-12-19 13:05 UbitUmarov Note Added: 0037406

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker