Server Deployments Week 42 – Recap
As always, please refer to the server deployment thread for updates and the latest information.
- There was no code promotion to the Main (SLS) channel on Tuesday, October 14th – this follows from there having been no deployments to the primary RC channels in week 41
- On Wednesday, October 15th, the primary RC channels were updated as follows:
HTTP Pipelining RC
On Wednesday October 15th, the Lab released the HTTP Pipelining RC viewer. Version 18.104.22.1685372 brings with it:
- Pipelined HTTP Operations for Mesh and Texture Fetches: this feature allows the viewer to issue multiple asset fetches on a connection without waiting for responses to earlier requests. This reduces the impact of a user’s physical location on scene loading and generally improves the experience for everyone
- Inventory Fetch Improvements: Inventory folder and item fetches are getting some of the same treatment that textures and meshes did in previous releases. Initial inventory load should be quicker and more robust for all users.
A blog post from Monty Linden accompanies the release, which provides further information on the HTTP project alongside of the viewer release notes.
Maintenance RC Viewer Removal
The latest Maintenance RC viewer, version 22.214.171.1244943, has been withdrawn from the release channel due to significant issues and a range of attachment bugs which affect it (see my week 41 update from the TPV developer meeting, under “AIS v3 Issues”).
As noted above, use of the CDN service for texture and mesh data was extended to the BlueSteel RC in week 42, and there is some anticipation within LL that it could be deployed to all three of the primary RCs sooner rather than later.
An issue has been noted on some regions running on the Snack RC where people are seeing very slow parcel information updates (e.g. the name of the parcel taking up to a full minute to appear in the status bar, for music stream changes to occur, etc.).
The thinking from the Lab is that these problems are a result of the Snack sim hosts receiving a top-heavy load of regions with high traffic counts, resulting in possible resource contentions with certain data lookups as a result – contentions which may have actually brought the regions down had it not been for the CDN, as Maestro Linden commented:
In the cases I’ve seen so far, the slowness was due to a rapid rate of requests from all the users logged into the regions. If the sim were serving all the texture and mesh requests as it traditionally would, the regions would have ‘fallen over’ before becoming that populated.
So this would seem to be an unintentional cloud with its own silver(ish) lining (at least the regions didn’t fall over). Nevertheless, the issue isn’t welcome. Given that BlueSteel has a more even distribution of regions across sim hosts (e.g. the servers are not all packed to the gills with high volume traffic regions), It is hoped that the issue will not exhibit itself there. Checks (either by the Lab or residents or both) are likely to be carried out on busy regions on the RC to see if the problem does raise its head, which might indicate some further investigations might be required.
Assuming all goes well with the BlueSteel deployment, it is thought that CDN support will likely extended to the remaining RCs sooner rather than later. In the meantime, for those interested in seeing how use of the CDN works for them, a list of regions by RC can be obtained via Tyche Shepherd’s Grid Survey website, allowing BlueSteel regions to be easily located. Just click the RC Server Regions button (note the list will require a little cleaning-up, post download).
DATA_BORN is the LSL function used to obtain the date an avatar was “born”. Some have noticed that under certain limited situations, it can return inconsistent results, with the date the targeted avatar was born differing by as much as a day when the query is run. Inconsistencies can occur both by running a query from the same region at set time periods (even as little as 15 minutes apart) or when running the query on one region, then immediately teleporting to another region and running it again.
Both Maestro and Simon Linden have poked at the issue, and are equally intrigued by it, with Maestro Linden commenting that the Lab may have to take a deeper poke at the look-up to see how it works, noting:
I thought it would just fetch a string from the database, but it seems to be doing something stranger. if the data were rapidly changing, there could be some differences based on the caching state of which sim you asked it on, but birth date shouldn’t change ever.
Mirrors Feature Request
Back in August 2014, I blogged about an attempt to implement real-time mirror reflections.
The initial work using viewer-side code developed by Zi Ree of the Firestorm team, had some limitations – as Zi was the first to admit, such as only working with the viewer in non-deferred mode (i.e. ALM off), for example. However, it did generate a lot of interest, and a feature request was raised which in turn sparked further debate (see STORM-2055), notably on the effectiveness of the approach (such as it being limited to planar surfaces), and on the potential for performance issues, the requirements for materials support, etc.
The work has also been looked at by the Lab, and as it stands at the moment, it is not something that they will likely pursue. Speaking at the Open-source Developer’s meeting on Monday, October 13th, Oz Linden said:
We’re not likely to do that. It’s very expensive in too many cases, and would cause more bug reports than not having it.
Unsurprisingly, Oz’s comment has drawn a further round of debate on the JIRA, and it is worthwhile taking the time to read through the comments posted there in full to gain a further understanding of the viewpoints involved, which are not restricted to just the Lab raising concerns.
Earlier in October, the SL Wiki was made read-only while it underwent maintenance, which was reported to be a security update during the Simulator User Group meeting on Tuesday October 7th. However, the wiki currently remains in read-only mode, with the latest update on the situation (Wednesday October 15th) indicating the work is still underway.