Beta Testing 1.25.3

See the post in the "Annoucnements" thread -- 1.25.3 is now on the "Second Life Beta Server" regions of aditi.

Prospero is llhttprequest enabled and still on the list of things to test? Also is there anything else specifically we should be looking to test and if so any advice on what vectors to use to test it. I figure that due to the limitations you've stated before we can't really test the load system (that and we don't have the tools to see most of the effects) but if there's anything we can do to test that I for one would be interesting in knowing.

Yeah, load testing is tough. llHttpRequest() should be working -- at the place where we hold office hours, Morris (192, 251, 35), there's a cube I dropped that does a basic test of it. I'm not sure if it works everywhere, but it does work some places.

What I'm *most* worried about is general script breakage... script functions we didn't think were affected by what we did. So, try out your favorite gadget.

Another thing that would be interesting to know is if scripts perform differently. This is tough to know, because lots of things change. You have to be sure that you're comparing performance on two regions that are on the same class of host... and, even then, you have to be sure that nobody else is spamming the heck out of that host on another region. (Unlikely, but still possible. on aditi.)

I'm updating 1.25.3 to 1.25.3.107171 on aditi right now.

I'm guessing that if nothing else this is going to screw anything that requires script timing up... again. Even though it has been said many times by Lindens not to rely on the timing mechanisms to be exactly accurate and I haven't had a chance to test this on 1.25.3 yet if my hunch is right there will probably be at least a few unhappy content creators.

OK what am I doing wrong?

I've tried a few 1.25.3.107171 sandbox sims... I can't create in Morris where I know for sure the code is. I've tried with viewers 1.21 and 1.22RC (there's no beta viewer at this time)... and http server calls/events won't compile for me.

The "Inner Strength" attachment function that hangs particle systems on people is broken again on Aditi. Actually it's the "poff" command that turns functions off that doesn't work...you may remember when I accidently discovered this a while back.

The weird thing about this is that it's also broken in Dore on Aditi...

You are at 255182.3, 256693.7, 47.7 in Dore located at sim3002.aditi.lindenlab.com (8.2.33.228:12035) Second Life Production Server 1.24.9.98659

So it's *not* the server version that's doing this. It's being on Aditi.

I wish I knew why, but I don't have the source and the builder is almost never in world anymore. But theer's something different over on Aditi still that keeps this thing from shutting off properly. But there's no reason to think it's related to the server code itself

Escort -- I just tried using llHTTPRequest in Sandbox Cordova, which is on 1.25.3, and it worked for me there.

Prospero, worked for me fine when testing last night too. Quick question though, I know that certain *.secondlife.com and secondlife.com/* sites are blocked from httprequest but is the main site http://www.secondlife.com blocked? I ask because that's the first address I tried to test with and it gave a blocked message... not that it really matters since there are better sites to use for testing (like a php page that will return some nice relevant data on your request) but I'm a curious person.

Escort, if you are trying at the meeting area that he gave the location to then you may not have joined the land group (it's open join I think) which you need to do to have build rights on that parcel. It's an annoying step but I guess Prospero is just really paranoid

I'm on Cordova and even the following does not compile...

default
{
    state_entry()
    {
        llRequestURL();
    }

}

...so it's my client version... I'm using...
Second Life 1.22.4 (106127) Dec 16 2008 12:22:22 (Second Life Release Candidate)
...which version do I need?

Ah! llRequestURL() won't work, as that's with HTTP-in. There are only a few sandboxes on Aditi that support that-- HTTP-in is *not* part of 1.25. That's still in an earlier beta phase.

llHTTPRequest is the function that will work-- that's been around for a while.

Wait... llHTTPRequest/http_response has been around for years, right? What changed? ah nm I'll reread the release notes. I thought this was the http server stuff we were testing!

edit: I see that instead it's just a bug that was introduced by 1.25 into an existing function. I'm pretty disappointed

/esc

Escort : I believe you are confused.

The script segment you quoted uses llRequestURL() -- that function does not exist in server 1.25.

llHTTPRequest() should be fully functional. There was a bug in an earlier version of 1.25, but that has been fixed. If you are finding new behavior that is not right, please file a JIRA or let us know what it is that you're seeing.

Maybe my memory is starting to fail me, but it seems to me that the last three times I checked the outages calendar, the 1.25.3 pilot roll has been pushed back a day each time. It's now set for Thursday.

I know it's tough to schedule this stuff...but I'm starting to worry that some shiny "new feature" is going to push ahead of the fixes in 1.25 and delay it even longer. Or has something showed up b0rken in .3?

Say it ain't so, Prospero...

Just small things that keep pushing it back a bit-- testing schedules. The latest day slip was due to wanting to get a small patch in that will reduce load on the central database, which I thought was a very important thing to slip in.

Sounds like Applehood and Mother Pie; we all want to see the database be performant. But I guess this confims my growing awareness that "not all server x.y.z are necessarily exactly the same code".

Yeah -- our algorithm for incrementing the third number is that once we hit agni, we bump the version number if we have to change it again. On aditi, you have to watch the fourth number to get something unique. However, also, once we're on aditi, *ideally* things don't change *too much* if the first three numbers are staying the same.

so far the limited testing I did aditi show no unexpected behavior or errors offcourse can only see script behavior and can only see backand behavior when it goes wrong in a big way

This may be slightly offtopic, but I point out that most people I know thought the Beta Grid couldn't be accessed right now: probably they thought so because there is no Preview Grid viewer available at this time at http://secondlife.com/support/downloads.php

This may confuse people that link the Preview Viewer to the Beta Grid, and most users probably don't know / remember the CTRL SHIFT G feature that makes the grid dropdown menu appear.

Yeah -- the full dirt can be found on:

http://wiki.secondlife.com/wiki/Preview_Grid

including instructions for getting the grid list and logging in to another grid with a standard client.

Prospero,

I changed my password and cannot log into Aditi. Can you get that reset for me? Thanx

Your old password will still work on Aditi until the next database refresh (which will probably happen sometime between 1.25 and 1.26).

Something seems to have changed with garbage collection in this release, that is totally breaking anything that tries to manipulate very large lists.

Previously, as far as we are guessing, garbage collection was performed whenever an operation that would potentially stack-heap was attempted, or somesuch. We are guessing that now the garbage collection is acting more like that of C#, that the garbage collector kind of runs asynchronously whenever it has time.

While this is a good idea on larger systems, the 64k heap limit of LSL makes this totally unfeasable. With lists taking up so much memory anyway, any kind of repeated manipulation without instantaneous garbage collection on any sizable list makes things break, badly.

I beg beg beg that this be fixed, either put back the way it was, or scripts given more heap space to cope with the changes. I predict that many existing mono scripts that fool with large lists are going to be crying.

Liandra, if you mean http://jira.secondlife.com/browse/SVC-3679 then I agree that's a serious issue that really needs to be looked at since it is breaking content.