Server Deployments – Week 36
As always, please refer to the week’s forum deployment thread for news, updates and feedback. Deployments are a day behind the usual schedule due to the US Labor Day long weekend.
- On Wednesday September 4th, the Main channel received the maintenance package deployed to all three RC channels in week 35, which includes Preparatory work to support new estate and parcel access controls and the new manual region restart capability which sees a region restart as soon as the last avatar leaves (release notes)
- On Thursday September 5th, the three RC channels received the same maintenance package, which comprises server-side HTTP updates which require a future viewer-side update. In the meantime, these changes should not be apparent in any current viewer release (release notes – BlueSteel)
Upcoming Server Deployments – Week 37
It looks likely that the HTTP updates deployed to all three RCs in week 36 (of which, more details below), will go back to just one RC in order to make way for additional packages “to get the server flow going again”.
Speaking at the Server Beta meeting on Thursday September 5th, Maestro Linden provided some information on some of the updates expected to go to at least one RC in week 37 (week commencing Monday September 9th):
- The llXorbase64 issue reported on in my week 35 (2) report for details
- A fix for an issue where an avatar sitting at high altitude may appear to be located at 0,0 on both the world map and mini map
- Nerfing of recursive rezzing. Again, this was outlined in my week 35 (1) report. Under the new code, the copy of the original object will inherit the temp-on-rez and parcel time of the originating object and so be returned at the same time.
- Fixes for a number of JSON function issues, including:
- JSON implementation treats blank string and JSON_NULL interchangeably
- Issue with llJsonSetValue with strings that end in ‘]’
- RFC 4627 Non-Compliance by llJsonSetValue() with out-of-range Indices
SL Viewer News
There were no changes to the SL release viewer this week, again most likely due to the long weekend in the US.
Snowstorm Project Viewer
As reviewed earlier in the week, there has been a new Snowstorm contributions project viewer released, which includes various fixes and Jonathan Yap’s request teleport feature and a port of Cinder Roxley’s “eject from group confirmation” pop-up.
Interest List Viewer
Delays continue with this viewer, largely as a result of bug stomping requirements. Commenting on the situation at the TPV Developer meeting, Oz Linden said:
As you might imagine, monkeying with the interest list is full of opportunities for errors; and I think the team is really sensitive to that and trying hard not to have a bad launch. I keep hearing status updates from them, but none of them have been, “We’re going to launch the viewer right away”.
Animation Override Interface
As reported in week 34, Oz Linden is looking-in to the possibility of developing a viewer-side API / hook into the LSL AO capabilities introduced server-side earlier in 2013. Initial discussions with the Lab’s own developers seemed to go well (or as Oz put it at the time, they didn’t run screaming from the room…
As Oz will shortly be in San Francisco in the near future, he’s going to poke some more at the idea with the people at Battery Street and “see if there is something we ought to be doing.” Again, this is still a nascent idea, even with the offer of import from Kitty Barnett, and Oz went on to say:
If this is going to happen, and it is still a major league “if”, I think we would want to do it as part of a project in which a substantial improvement was made to how the viewer interacts with animation in general, and that means I would want a set of open-source devs involved in doing the viewer-side work. So be thinking about whether or not you can commit to that.
There is still no date as to when the Server-side Appearance RC viewer will appear. This will be the viewer containing the additional inventory-side improvements, code clean-up (removal of the “old” baking code from the viewer), and other nips and tucks. However, the internal repository within the Lab has now been merged-up to viewer release, so the viewer is up-to-date with the current release viewer .
At the Server Beta meeting on Thursday September 5th, Monty Linden gave a further overview of the new HTTP capabilities deployed to the RC channels. In essence, and as previously covered:
- There is a new capability – GetMesh2 – which reduces the number of concurrent number of mesh connections from 32 to 8, but which adds keepalive functionality and improved retry logic . This is in preparation for HTTP pipelining, and a future move to combine mesh and HTTP texture request paths into a single channel (essentially, fewer connections but each handling more downloads more efficiently). As noted in the report linked-to above, this should allow the Lab to further improve connectivity between the viewer and their servers, resulting in a better service on both sides of the equation, and benefit those users with high bandwidth / high latency connections
- GetMesh2 will have a new debug setting, Mesh2MaxCocurrentRequests. Again, as previously reported, this will be clamped at 8 to prevent situations seen with the current debug, MeshMaxCocurrentRequests, where users set the debug to ridiculously high values (e.g. 500), in the mistaken belief that this will “improve” mesh downloads for them, when in fact it simply leads to exceeding the service capacity, generates a lot of 503 errors and risks possible congestive collapse.
- As the new capabilities are being transitioned-in to the grid, the Lab will be clamping the current MeshMaxConcurrentRequests. What the clamp might be is still unclear, although Monty has already indicated it will be “well under 100”. In line with this, Firestorm has already clamped the debug at 64 in their upcoming release.
One of the problems inherent in the current system is that when the server cannot handle a request, it can respond with a 503 error; however, as the viewer currently has a “retry-as-fast-as-possible” policy. This means that situations can occur with mesh downloads (particularly where MeshMaxConcurrentRequests is set too high) where the server 503’s, the viewer demands an immediate retry, generating a further 503, and so on, until all retries are 503’d and the user never sees any progress.
GetMesh2 (and the upcoming viewer-side changes) will hopefully avoid this because GetMesh2 will include the ability to return information in the 503 header on when the viewer should retry. This may not always be sent, but when it is, the viewer should heed the request; when the information isn’t sent, the viewer will make ‘reasonable, best-practices’ delayed retry attempts. This retry logic will be applicable to any request that is subject to cap throttling.
A further improvement to the system is that currently, when connections between viewer and web services are closed by the server, the last response is sent without a ‘Content-Length’ or ‘Transfer-Encoding: chunked’ header. The new code on the RCs will now send the last response with “chunked” encoding. This will allow the upcoming viewer and libcurl to validate that the viewer really received and full response, or whether a retry is required.
The viewer code is currently being tested, and Monty indicates things are progressing well, although it’s not clear whether the updates will appear in a project viewer or go directly to release candidate status. However, Monty has previously hinted that it could appear during September.